linux-kernel - Re: [PATCH] random: use correct memory barriers for crng_node

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: <20200921152714.GC29330@paulmck-ThinkPad-P72>
Date:   Mon, 21 Sep 2020 08:27:14 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     Eric Biggers <ebiggers@...nel.org>, tytso@....edu,
        linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        stable@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] random: use correct memory barriers for crng_node_pool

On Mon, Sep 21, 2020 at 06:19:39PM +1000, Herbert Xu wrote:
> On Thu, Sep 17, 2020 at 09:58:02AM -0700, Eric Biggers wrote:
> >
> > smp_load_acquire() is obviously correct, whereas READ_ONCE() is an optimization
> > that is difficult to tell whether it's correct or not.  For trivial data
> > structures it's "easy" to tell.  But whenever there is a->b where b is an
> > internal implementation detail of another kernel subsystem, the use of which
> > could involve accesses to global or static data (for example, spin_lock()
> > accessing lockdep stuff), a control dependency can slip in.
> 
> If we're going to follow this line of reasoning, surely you should
> be converting the RCU derference first and foremost, no?

Agreed, rcu_dereference() is preferred over READ_ONCE() when reading
RCU-protected pointers.  Much better debugging support, if nothing else.

However, as part of making the kernel safe from DEC Alpha, READ_ONCE()
does protect against reading and dereferencing pointers to objects
concurrently being inserted into a linked data structure.  If they are
never removed (or are removed only when there are known to be no readers),
RCU is not required.

And to Eric's point, it is also true that when you have pointers to
static data, and when the compiler can guess this, you do need something
like smp_load_acquire().  But this is a problem only when you are (1)
using feedback-driven compiler optimization or (2) when you compare the
pointer to the address of the static data.

And yes, we are still working to be able to tell the compiler when
a pointer carries a dependency, but this continues to be slow going.  :-/

							Thanx, Paul