[PATCH] x86/uaccess: Avoid barrier_nospec() in copy_from_user()

[Andrew Cooper]

On 14/10/2024 7:50 am, Linus Torvalds wrote:
> On Sun, 13 Oct 2024 at 20:54, Josh Poimboeuf <jpoimboe at kernel.org> wrote:
>> If I understand correctly, LAM bits are for the benefit of SW and are
>> ignored by HW?

That is what is written in the ISE today.

But, I'll note that on ARM, MTE (Memory Tagging Extensions) use the same
bits that BTI (Top Byte Ignore) made available to software.

>>> So maybe the "what is the actual cycle latency of detecting the
>>> faulting instruction" really is the core question here.

I'm afraid I will have to defer that to AMD.  I have not experimented
personally.


>> I think I remember reading that STAC/CLAC can't necessarily be relied on
>> as a speculation barrier, depending on microarchitectural details.

STAC and CLAC are not LFENCEes.

They happen to be on implementations where AC is not a renamed flag
(i.e. can't be updated speculatively), but both vendors want the
flexibility in the future.

Therefore, it is my recollection that the vendors agreed that STAC/CLAC
would prevent memory accesses from occurring under the wrong AC,
although I can't actually find this written down anywhere.

I think we need to chase some architects until a statement or two fall out.


>> It
>> might be safest to assume we can't rely on that.  Masking is relatively
>> cheap anyway.
> The WHOLE BUG is all about "microarchitectural details".
>
> So arguing that STAC is a microarchitectural detail and not
> architecturally guaranteed isn't an argument.
>
> Because architecturally, this but simply does not exist, and so some
> architectural definition simply doesn't matter.
>
> So all that matters is whether the broken microarchitectures that used
> the wrong bit for testing also have a STAC that basically hides the
> bug.
>
> Christ. The hardware should have used a bit that is *MEANINGFUL*,
> namely bit #63, not some random meaningless bit that just happens to
> be one of the bits that is then checked for canonicality.
>
> And it's so annoying, because from a *hardware* perspective, bit #63
> vs bit #48 is completely irrelevant. It's literally just a wire choice
>
> But from an architectural perspective, bit #63 is not only the
> *actual* bit that is the real difference  ("kernel is at the top of
> the address space") but for software, bit #48 is fundamentally harder
> to test.
>
> IOW, it's completely the wrong effing bit to test.
>
> Honestly, the Intel meltdown thing I at least understood *why* it happened.
>
> This AMD "use meaningless bit #48" bug just strikes me as active malice.

I think this is unfair.

This was an implementation decision taken probably around the millennium
(given lead times to get the K8 out in 2003).

There is a reason why - given they're architecturally equivalent - the
inside bit is more useful than the outside bit.  Some AMD CPUs really
only have 48 bits of storage for pointers, and it really does simplify
circuitry.

Furthermore, since when have software concerns (one bit being harder to
test than others) ever factored into hardware design.  It's sad but true.