linux-kernel - Re: [RFC PATCH] LKMM: Add ctrl_dep() macro for control dependency

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]

Message-ID: <CAHk-=whrmpKUbJp1gmY3tyNCw6YebEZO1Cd8GzsL_4WFf-obDQ@mail.gmail.com>
Date:   Thu, 14 Oct 2021 18:36:28 -0400
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     Florian Weimer <fw@...eb.enyo.de>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        Will Deacon <will@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Alan Stern <stern@...land.harvard.edu>,
        Andrea Parri <parri.andrea@...il.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Nicholas Piggin <npiggin@...il.com>,
        David Howells <dhowells@...hat.com>,
        j alglave <j.alglave@....ac.uk>,
        luc maranget <luc.maranget@...ia.fr>,
        akiyks <akiyks@...il.com>,
        linux-toolchains <linux-toolchains@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [RFC PATCH] LKMM: Add ctrl_dep() macro for control dependency

On Thu, Oct 14, 2021 at 5:10 PM Paul E. McKenney <paulmck@...nel.org> wrote:
>
> In all the weakly ordered architectures I am aware of, spilling to
> the stack and reloading preserves the ordering.  The ordering from
> the initial load to the spill is an assembly-language data dependency,
> the ordering from the spill to the reload is single-variable SC, and
> the ordering beyond that is the original control dependency.

I think the thing about a control dependency is that any way to
optimize it differently only strengthens it.

That was very different from the problems we had with describing the
RCU dependencies - they were data dependencies, and if they could ever
be turned into control dependencies, they would have been weakened.

But the only way to really weaken a control dependency and the write
behind it is to get rid of it entirely.

So turning it into a data dependency (by turning the conditional into
a 'select' instruction, for example) only makes it stronger. And no
amount of register spilling or data movement any other way makes any
difference.

That's why all the examples of what could go wrong were about same
code on both sides of the conditional, which allowed removing the
conditional entirely (or at least moving parts of the "protected" code
to before it.

(The other way to remove the conditional is to just optimize away the
conditional itself, but that's defeated by "READ_ONCE()" being part of
the source of the conditional, and any data or control dependency from
that fundamental "the compiler cannot remove this logic" is always
sufficient).

So I really don't think this is even about "any weakly ordered
architecture". I think this is fundamentally about causality. You
simply cannot make a conditional write visible before the condition
has been resolved, and resolving the condition requires the read to
have happened.

This is not open to "speculation". Not by hardware, not by compilers.

There are only two ways you can break this fundamental construct:

 - outright bugs

 - a perfect oracle

And honestly, if you have a perfect oracle, you're better off making
money playing the lotto than you would ever be doing hardware or
software development, so that second option isn't really even
interesting.

                 Linus