From: Alexander Popov <alex.popov@linux.com>
To: Julia Lawall <julia.lawall@inria.fr>
Cc: Michal Marek <michal.lkml@markovi.net>,
Kees Cook <keescook@chromium.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Jann Horn <jannh@google.com>,
Nicolas Palix <nicolas.palix@imag.fr>,
LKML <linux-kernel@vger.kernel.org>,
Hans Verkuil <hverkuil@xs4all.nl>,
Markus Elfring <Markus.Elfring@web.de>,
Gilles Muller <Gilles.Muller@lip6.fr>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
cocci@systeme.lip6.fr,
Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [Cocci] Coccinelle rule for CVE-2019-18683
Date: Thu, 9 Apr 2020 22:56:57 +0300 [thread overview]
Message-ID: <3c92523d-4b3f-e805-84e6-6abd1eedd683@linux.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2004091248190.2403@hadrien>
On 09.04.2020 13:53, Julia Lawall wrote:
> On Thu, 9 Apr 2020, Alexander Popov wrote:
>> virtual report
>>
>> @race exists@
>> expression E;
>> position stop_p;
>> position unlock_p;
>> position lock_p;
>> @@
>>
>> mutex_unlock@unlock_p(E)
>> ...
>
> It would be good to put when != mutex_lock(E) after the ... above. Your
> rule doesn't actually prevent the lock from being retaken.
Thanks Julia! I used this trick in the second version of the rule that I've just
sent.
>> kthread_stop@stop_p(...)
>> ...
>> mutex_lock@lock_p(E)
>>
>> @script:python@
>> stop_p << race.stop_p;
>> unlock_p << race.unlock_p;
>> lock_p << race.lock_p;
>> E << race.E;
>> @@
>>
>> coccilib.report.print_report(unlock_p[0], 'mutex_unlock(' + E + ') here')
>> coccilib.report.print_report(stop_p[0], 'kthread_stop here')
>> coccilib.report.print_report(lock_p[0], 'mutex_lock(' + E + ') here\n')
...
> Based on Jann's suggestion, it seem like it could be interesting to find
> these locking pauses, and then collect functions that are used in locks
> and in lock pauses. If a function is mostly used with locks held, then
> using it in a lock pause could be a sign of a bug. I will see if it turns
> up anything interesting.
Do you mean collecting the behaviour that happens between unlocking and locking
and then analysing it somehow?
Best regards,
Alexander
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Popov <alex.popov@linux.com>
To: Julia Lawall <julia.lawall@inria.fr>
Cc: Gilles Muller <Gilles.Muller@lip6.fr>,
Nicolas Palix <nicolas.palix@imag.fr>,
Michal Marek <michal.lkml@markovi.net>,
cocci@systeme.lip6.fr,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Jann Horn <jannh@google.com>, Kees Cook <keescook@chromium.org>,
Hans Verkuil <hverkuil@xs4all.nl>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Markus Elfring <Markus.Elfring@web.de>
Subject: Re: [Cocci] Coccinelle rule for CVE-2019-18683
Date: Thu, 9 Apr 2020 22:56:57 +0300 [thread overview]
Message-ID: <3c92523d-4b3f-e805-84e6-6abd1eedd683@linux.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2004091248190.2403@hadrien>
On 09.04.2020 13:53, Julia Lawall wrote:
> On Thu, 9 Apr 2020, Alexander Popov wrote:
>> virtual report
>>
>> @race exists@
>> expression E;
>> position stop_p;
>> position unlock_p;
>> position lock_p;
>> @@
>>
>> mutex_unlock@unlock_p(E)
>> ...
>
> It would be good to put when != mutex_lock(E) after the ... above. Your
> rule doesn't actually prevent the lock from being retaken.
Thanks Julia! I used this trick in the second version of the rule that I've just
sent.
>> kthread_stop@stop_p(...)
>> ...
>> mutex_lock@lock_p(E)
>>
>> @script:python@
>> stop_p << race.stop_p;
>> unlock_p << race.unlock_p;
>> lock_p << race.lock_p;
>> E << race.E;
>> @@
>>
>> coccilib.report.print_report(unlock_p[0], 'mutex_unlock(' + E + ') here')
>> coccilib.report.print_report(stop_p[0], 'kthread_stop here')
>> coccilib.report.print_report(lock_p[0], 'mutex_lock(' + E + ') here\n')
...
> Based on Jann's suggestion, it seem like it could be interesting to find
> these locking pauses, and then collect functions that are used in locks
> and in lock pauses. If a function is mostly used with locks held, then
> using it in a lock pause could be a sign of a bug. I will see if it turns
> up anything interesting.
Do you mean collecting the behaviour that happens between unlocking and locking
and then analysing it somehow?
Best regards,
Alexander
next prev parent reply other threads:[~2020-04-09 19:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-08 22:01 [Cocci] Coccinelle rule for CVE-2019-18683 Alexander Popov
2020-04-08 22:01 ` Alexander Popov
2020-04-08 22:26 ` [Cocci] " Jann Horn
2020-04-08 22:26 ` Jann Horn
2020-04-09 19:41 ` [Cocci] " Alexander Popov
2020-04-09 19:41 ` Alexander Popov
2020-04-11 0:10 ` [Cocci] " Alexander Popov
2020-04-11 0:10 ` Alexander Popov
2020-04-11 5:07 ` [Cocci] " Markus Elfring
2020-04-11 5:07 ` Markus Elfring
2020-04-09 10:53 ` [Cocci] " Julia Lawall
2020-04-09 10:53 ` Julia Lawall
2020-04-09 19:56 ` Alexander Popov [this message]
2020-04-09 19:56 ` Alexander Popov
2020-04-09 20:45 ` Julia Lawall
2020-04-09 20:45 ` Julia Lawall
-- strict thread matches above, loose matches on Subject: below --
2020-04-09 8:41 Markus Elfring
2020-04-09 8:41 ` Markus Elfring
2020-04-09 18:11 ` Alexander Popov
2020-04-09 18:11 ` Alexander Popov
2020-04-10 13:16 ` Markus Elfring
2020-04-10 13:16 ` Markus Elfring
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=3c92523d-4b3f-e805-84e6-6abd1eedd683@linux.com \
--to=alex.popov@linux.com \
--cc=Gilles.Muller@lip6.fr \
--cc=Markus.Elfring@web.de \
--cc=cocci@systeme.lip6.fr \
--cc=hverkuil@xs4all.nl \
--cc=jannh@google.com \
--cc=julia.lawall@inria.fr \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.