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] [day] [month] [year] [list]
Date:	Fri, 17 Jun 2016 17:28:14 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, corbet@....net, will.deacon@....com,
	peterz@...radead.org
Subject: Re: [PATCH Documentation/memory-barriers.txt] Clarify limited
 control-dependency scope

On Fri, Jun 17, 2016 at 09:53:50AM +0200, Ingo Molnar wrote:
> 
> * Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> 
> > Nothing in the control-dependencies section of memory-barriers.txt
> > says that control dependencies don't extend beyond the end of the
> > if-statement containing the control dependency.  Worse yet, in many
> > situations, they do extend beyond that if-statement.  In particular,
> > the compiler cannot destroy the control dependency given proper use of
> > READ_ONCE() and WRITE_ONCE().  However, a weakly ordered system having
> > a conditional-move instruction provides the control-dependency guarantee
> > only to code within the scope of the if-statement itself.
> > 
> > This commit therefore adds words and an example demonstrating this
> > limitation of control dependencies.
> > 
> > Reported-by: Will Deacon <will.deacon@....com>
> > Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> > Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> > 
> > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> > index 147ae8ec836f..a4d0a99de04d 100644
> > --- a/Documentation/memory-barriers.txt
> > +++ b/Documentation/memory-barriers.txt
> > @@ -806,6 +806,41 @@ out-guess your code.  More generally, although READ_ONCE() does force
> >  the compiler to actually emit code for a given load, it does not force
> >  the compiler to use the results.
> >  
> > +In addition, control dependencies apply only to the then-clause and
> > +else-clause of the if-statement in question.  In particular, it does
> > +not necessarily apply to code following the if-statement:
> > +
> > +	q = READ_ONCE(a);
> > +	if (q) {
> > +		WRITE_ONCE(b, p);
> > +	} else {
> > +		WRITE_ONCE(b, r);
> > +	}
> > +	WRITE_ONCE(c, 1);  /* BUG: No ordering against the read from "a". */
> > +
> > +It is tempting to argue that there in fact is ordering because the
> > +compiler cannot reorder volatile accesses and also cannot reorder
> > +the writes to "b" with the condition.  Unfortunately for this line
> > +of reasoning, the compiler might compile the two writes to "b" as
> > +conditional-move instructions, as in this fanciful pseudo-assembly
> > +language:
> 
> While CMOV would be the typical situation, even without CMOV the compiler could 
> also internally transform it to:
> 
> > +	if (q)
> > +		WRITE_ONCE(b, p);
> > +	if (!q)
> > +		WRITE_ONCE(b, r);
> 
> ... and CPU speculation flow could get past the two branches without seeing any 
> ordering constraint with the writes to 'b'.
> 
> I.e. conditions are not 'atomic', they can be 'torn' by the compiler just as much 
> as reads or writes can be torn.

That is an interesting test case!

PowerPC prohibits speculating the writes in your transformed case, that is,
prohibits the writes to "b" from being reordered with the read from "a".
I believe that ARM also prohibits it in that case, but must defer to
Will Deacon.  Not sure about MIPS.

Or am I misunderstanding your intent with that example?

							Thanx, Paul

Powered by blists - more mailing lists