linux-kernel - RE: [PATCH] list: Prevent compiler reloads inside 'safe' list iteration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <158384100886.16414.15741589015363013386@build.alporthouse.com>
Date:   Tue, 10 Mar 2020 11:50:08 +0000
From:   Chris Wilson <chris@...is-wilson.co.uk>
To:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        David Laight <David.Laight@...LAB.COM>
Cc:     "intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCH] list: Prevent compiler reloads inside 'safe' list iteration

Quoting David Laight (2020-03-10 11:36:41)
> From: Chris Wilson
> > Sent: 10 March 2020 09:21
> > Instruct the compiler to read the next element in the list iteration
> > once, and that it is not allowed to reload the value from the stale
> > element later. This is important as during the course of the safe
> > iteration, the stale element may be poisoned (unbeknownst to the
> > compiler).
> 
> Eh?
> I thought any function call will stop the compiler being allowed
> to reload the value.
> The 'safe' loop iterators are only 'safe' against called
> code removing the current item from the list.
> 
> > This helps prevent kcsan warnings over 'unsafe' conduct in releasing the
> > list elements during list_for_each_entry_safe() and friends.
> 
> Sounds like kcsan is buggy ????

The warning kcsan gave made sense (a strange case where the emptying the
list from inside the safe iterator would allow that list to be taken
under a global mutex and have one extra request added to it. The
list_for_each_entry_safe() should be ok in this scenario, so long as the
next element is read before this element is dropped, and the compiler is
instructed not to reload the element. kcsan is a little more insistent
on having that annotation :)

In this instance I would say it was a false positive from kcsan, but I
can see why it would complain and suspect that given a sufficiently
aggressive compiler, we may be caught out by a late reload of the next
element.

That's my conjecture, but I leave it to the lkmm experts to decide :)
-Chris