linux-kernel - Re: [PATCH locking/Documentation 1/2] Add note of release-acquire store vulnerability

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: <20160929164353.GX14933@linux.vnet.ibm.com>
Date:   Thu, 29 Sep 2016 09:43:53 -0700
From:   "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:     Will Deacon <will.deacon@....com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, mingo@...nel.org,
        dhowells@...hat.com, stern@...land.harvard.edu
Subject: Re: [PATCH locking/Documentation 1/2] Add note of release-acquire
 store vulnerability

On Thu, Sep 29, 2016 at 05:03:08PM +0100, Will Deacon wrote:
> On Thu, Sep 29, 2016 at 05:58:17PM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 29, 2016 at 08:54:01AM -0700, Paul E. McKenney wrote:
> > > If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
> > > broken if a third process overwrites the value written by the RELEASE
> > > operation before the ACQUIRE operation has a chance of reading it.
> > > This commit therefore updates the documentation to call this vulnerability
> > > out explicitly.
> > > 
> > > Reported-by: Alan Stern <stern@...land.harvard.edu>
> > > Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > 
> > > +     However, please note that a chain of RELEASE+ACQUIRE pairs may be
> > > +     broken by a store by another thread that overwrites the RELEASE
> > > +     operation's store before the ACQUIRE operation's read.
> > 
> > This is the powerpc lwsync quirk, right? Where the barrier disappears
> > when it looses the store.
> > 
> > Or is there more to it? Its not entirely clear from the Changelog, which
> > I feel should describe the reason for the behaviour.
> 
> If I've groked it correctly, it's for cases like:
> 
> 
> PO:
> Wx=1
> WyRel=1
> 
> P1:
> Wy=2
> 
> P2:
> RyAcq=2
> Rx=0
> 
> Final value of y is 2.
> 
> 
> This is permitted on arm64. If you make P1's store a store-release, then
> it's forbidden, but I suspect that's not generally true of the kernel
> memory model.

That is the one!  And to Peter's point, powerpc does the same for the
example as shown.  However, on powerpc, upgrading P1's store to release
has no effect because there is no earlier access for the resulting
lwsync to influence.  For whatever it might be worth, C11 won't guarantee
ordering in that case, either.  Nor will the current Linux-kernel memory
model.  (Yes, I did just try it to make sure.  Why do you ask?)

So you guys are fishing for an expanded commit log, for example, like
the following?  ;-)

							Thanx, Paul

------------------------------------------------------------------------

If two processes are related by a RELEASE+ACQUIRE pair, ordering can be
broken if a third process overwrites the value written by the RELEASE
operation before the ACQUIRE operation has a chance of reading it, for
example:

	P0(int *x, int *y)
	{
		WRITE_ONCE(*x, 1);
		smp_wmb();
		smp_store_release(y, 1);
	}

	P1(int *y)
	{
		smp_store_release(y, 2);
	}

	P2(int *x, int *y)
	{
		r1 = smp_load_acquire(y);
		r2 = READ_ONCE(*x);
	}

Both ARM and powerpc allow the "after the dust settles" outcome (r1=2 &&
r2=0), as does the current version of the early prototype Linux-kernel
memory model.

This commit therefore updates the documentation to call this vulnerability
out explicitly.