From: Markus Elfring <Markus.Elfring@web.de>
To: Alexander Popov <alex.popov@linux.com>,
cocci@systeme.lip6.fr, kernel-hardening@lists.openwall.com
Cc: Michal Marek <michal.lkml@markovi.net>,
Kees Cook <keescook@chromium.org>,
Gilles Muller <Gilles.Muller@lip6.fr>,
Jann Horn <jannh@google.com>,
Nicolas Palix <nicolas.palix@imag.fr>,
linux-kernel@vger.kernel.org, Hans Verkuil <hverkuil@xs4all.nl>,
Julia Lawall <Julia.Lawall@lip6.fr>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-media@vger.kernel.org
Subject: Re: [Cocci] Coccinelle rule for CVE-2019-18683
Date: Fri, 10 Apr 2020 15:16:57 +0200 [thread overview]
Message-ID: <840858a4-2440-3fbd-297a-db2dacbcf24c@web.de> (raw)
In-Reply-To: <9a562397-ba60-8979-1453-b88153722803@linux.com>
>> * The source code search pattern can be too generic.
>> How do you think about to consider additional constraints
>> for safer data control flow analysis?
>
> Could you please elaborate on that?
Julia Lawall chose to mention the design possibility “put when
!= mutex_lock(E) after the ...”.
https://systeme.lip6.fr/pipermail/cocci/2020-April/007107.html
https://lore.kernel.org/cocci/alpine.DEB.2.21.2004091248190.2403@hadrien/
> I used 'exists' keyword to find at least one branch that has
> mutex_unlock+kthread_stop+mutex_lock chain.
Are you informed about development challenges for data flow analysis
(or even escape analysis according to computer science)?
How many experiences can be reused from other known approaches?
Regards,
Markus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
next prev parent reply other threads:[~2020-04-10 13:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-09 8:41 [Cocci] Coccinelle rule for CVE-2019-18683 Markus Elfring
2020-04-09 18:11 ` Alexander Popov
2020-04-10 13:16 ` Markus Elfring [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-04-08 22:01 Alexander Popov
2020-04-08 22:26 ` Jann Horn
2020-04-09 19:41 ` Alexander Popov
2020-04-11 0:10 ` Alexander Popov
2020-04-11 5:07 ` Markus Elfring
2020-04-09 10:53 ` Julia Lawall
2020-04-09 19:56 ` Alexander Popov
2020-04-09 20:45 ` Julia Lawall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=840858a4-2440-3fbd-297a-db2dacbcf24c@web.de \
--to=markus.elfring@web.de \
--cc=Gilles.Muller@lip6.fr \
--cc=Julia.Lawall@lip6.fr \
--cc=alex.popov@linux.com \
--cc=cocci@systeme.lip6.fr \
--cc=hverkuil@xs4all.nl \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=nicolas.palix@imag.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).