linux-kernel - Re: [RFC] LKMM: Add volatile

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: <20210805194749.GA436115@rowland.harvard.edu>
Date:   Thu, 5 Aug 2021 15:47:49 -0400
From:   Alan Stern <stern@...land.harvard.edu>
To:     Jade Alglave <j.alglave@....ac.uk>
Cc:     Will Deacon <will@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Andrea Parri <parri.andrea@...il.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Nick Piggin <npiggin@...il.com>,
        David Howells <dhowells@...hat.com>,
        Luc Maranget <luc.maranget@...ia.fr>,
        Akira Yokosawa <akiyks@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-toolchains@...r.kernel.org,
        linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [RFC] LKMM: Add volatile_if()

On Fri, Jul 30, 2021 at 06:20:22PM +0100, Jade Alglave wrote:
> I hope this material can help inform this conversation and I would love
> to hear your thoughts.

Thoughts on section 3...

The paragraph on Branching Effect is pretty meager.  Exactly what 
effects does a conditional branch instruction generate?  I imagine 
there's a register read of the flags register, to see whether the branch 
should be taken.  And evidently there's a branch effect, which may take 
the register read as input but doesn't have any obvious outputs.  
Anything else? -- there don't seem to be any register writes.

Why are Store Exclusive instructions explicitly disallowed in the 
definition of dependency through registers?  Is this because ARM CPUs 
don't forward values written by such instructions to po-later reads?  If 
so, why don't they?  (Paul asked a similar question.)

Since the recursive definition of dependency through registers starts 
with either a register write or intrinsic order of events in an 
instruction, it appears that there cannot be any dependency through 
registers starting from a branching effect.  So why does the definition 
of address dependency talk about a dependency through registers from B4 
(a branching effect) to R2?  (Paul also asked about this -- does writing 
to the program counter get treated as a register write?  But almost no 
instructions explicitly read from the program counter.)

What is the whole point of the special handling of branching effects in 
the definition of address dependencies?  It isn't obvious and the text 
doesn't explain it.

Figure 26 includes a lot of terms that seem like herd primitives.  They 
must be relatively new, because they aren't mentioned in the 
documentation that I've got.  (I'm referring to such terms as iico_data, 
iico_ctrl, intrinsic, same-instance, DATA, and NDATA.)  Are they 
explained anywhere?

Way back in Section 1, various Intrinsic dependency relations were 
introduced.  The reason for treating Intrinsic control dependencies 
specially seems to be that the CPU can speculate past such dependencies 
(though it would be nice if the text made this point explicitly).  But 
why do you differentiate between data and order Intrinsic dependencies?  
Is this also related to some specific behavior of ARM CPUs?

Alan