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: <YL34NZ12mKoiSLvu@hirez.programming.kicks-ass.net>
Date:   Mon, 7 Jun 2021 12:43:01 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Alan Stern <stern@...land.harvard.edu>,
        Segher Boessenkool <segher@...nel.crashing.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Will Deacon <will@...nel.org>,
        Andrea Parri <parri.andrea@...il.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Nick Piggin <npiggin@...il.com>,
        David Howells <dhowells@...hat.com>,
        Jade Alglave <j.alglave@....ac.uk>,
        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 Sun, Jun 06, 2021 at 11:43:42AM -0700, Linus Torvalds wrote:
> So while the example code is insane and pointless (and you shouldn't
> read *too* much into it), conceptually the notion of that pattern of
> 
>     if (READ_ONCE(a)) {
>         WRITE_ONCE(b,1);
>         .. do something ..
>     } else {
>         WRITE_ONCE(b,1);
>         .. do something else ..
>     }

This is actually more tricky than it would appear (isn't it always).

The thing is, that normally we must avoid speculative stores, because
they'll result in out-of-thin-air values.

*Except* in this case, where both branches emit the same store, then
it's a given that the store will happen and it will not be OOTA.
Someone's actually done the proof for that apparently (Will, you have a
reference to Jade's paper?)

There's apparently also a competition going on who can build the
weakestest ARM64 implementation ever.

Combine the two, and you'll get a CPU that *will* emit the store early
:/

So it might be prudent to make this pattern as difficult as possible (a
compiler implementation of volatile_if might be able to observe and WARN
about this).

How's something like (leaving the improved barrier() aside for now):

#define volatile_if(x) \
	if (!(({ _Bool __x = (x); BUILD_BUG_ON(__builtin_constant_p(__x)); __x; }) && \
	     ({ barrier(); 1; }))) { } else

That makes writing:

	volatile_if(READ_ONCE(a)) {
		WRITE_ONCE(b, 1);
		// something
	} else {
		WRITE_ONCE(b, 1);
		// something else
	}

A syntax error, due to volatile_if() already being an else. And yes,
there's plenty other ways to write the same :/