linux-kernel - Re: [PATCH 1/1] x86: In x86-64 barrier

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: <20250209214047.4552e806@pumpkin>
Date: Sun, 9 Feb 2025 21:40:47 +0000
From: David Laight <david.laight.linux@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, Thomas Gleixner
 <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
 <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin"
 <hpa@...or.com>, Catalin Marinas <catalin.marinas@....com>, Mathieu
 Desnoyers <mathieu.desnoyers@...icios.com>, Josh Poimboeuf
 <jpoimboe@...hat.com>, Andi Kleen <ak@...ux.intel.com>, Dan Williams
 <dan.j.williams@...el.com>, linux-arch@...r.kernel.org, Kees Cook
 <keescook@...omium.org>, kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH 1/1] x86: In x86-64 barrier_nospec can always be lfence

On Sun, 9 Feb 2025 11:32:32 -0800
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Sun, 9 Feb 2025 at 11:10, David Laight <david.laight.linux@...il.com> wrote:
> >
> > +#define barrier_nospec() __rmb()  
> 
> This is one of those "it happens to work, but it's wrong" things.
> 
> Just make it explicit that it's "lfence" in the current implementation.

Easily done.

Any idea what the one used to synchronise rdtsc should be?
'lfence' is the right instruction (give or take), but it isn't
a speculation issue.
It really is 'wait for all memory accesses to finish' to give
a sensible(ish) answer for cycle timing.
And on old cpu you want nothing - not a locked memory access.

> 
> Is __rmb() also an lfence? Yes. And that's actually very confusing too
> too. Because on x86, a regular read barrier is a no-op, and the "main"
> rmb definition is actually this:
> 
>   #define __dma_rmb()     barrier()
>   #define __smp_rmb()     dma_rmb()
> 
> so that it's only a compiler barrier.

I couldn't work out why __smp_mb() is so much stronger than the rmb()
and wmb() forms - I presume the is history there I wasn't looking for.

> And yes, __rmb() exists as the architecture-specific helper for "I
> need to synchronize with unordered IO accesses" and is purely about
> driver IO.

I'd missed the history of it being IO related.

...
> And some day in the future, maybe even that implementation equivalence
> ends up going away again, and we end up with new barrier instructions
> that depend on new CPU capabilities (or fake software capabilities:
> kernel bootup flags that say "don't bother with the nospec
> barriers").

Actually there is already the cpu flag to treat addresses with the top
bit set as 'supervisor' in the initial address decode - rather that
checking the page table in parallel with the d-cache accesses.
When that hits real silicon then patching out the barrier_nospec()
lfence would make sense.
There is also your kernel build machine where you don't care.
So compiling them out or boot patching them out is a real option.

This does make it more clear that the rdtsc code has the wrong barrier.

> So please keep the __rmb() and the barrier_nospec() separate, don't
> tie them together. They just have *soo* many differences, both
> conceptual and practical.

A simple V2 :-)

	David

> 
>              Linus