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

Andrew Cooper andrew.cooper3 at citrix.com
Thu Oct 17 09:02:56 AEDT 2024


On 16/10/2024 5:10 pm, Linus Torvalds wrote:
>   --- a/arch/x86/lib/getuser.S
>   +++ b/arch/x86/lib/getuser.S
>   @@ -37,11 +37,14 @@
>
>    #define ASM_BARRIER_NOSPEC ALTERNATIVE "", "lfence", X86_FEATURE_LFENCE_RDTSC
>
>   +#define X86_CANONICAL_MASK ALTERNATIVE \
>   +     "movq $0x80007fffffffffff,%rdx", \
>   +     "movq $0x80ffffffffffffff,%rdx", X86_FEATURE_LA57
>   +
>    .macro check_range size:req
>    .if IS_ENABLED(CONFIG_X86_64)
>   -     mov %rax, %rdx
>   -     sar $63, %rdx
>   -     or %rdx, %rax
>   +     X86_CANONICAL_MASK      /* mask into %rdx */
>   +     and %rdx,%rax

That doesn't have the same semantics, does it?

Consider userspace passing an otherwise-good pointer with bit 60 set. 
Previously that would have resulted in a failure, whereas now it will
succeed.


If AMD think it's appropriate, then what you probably want is the real
branch as per before (to maintain architectural user behaviour), and
then use a trick such as this one in place of the LFENCE for speed in
the common case.

> But in (related) news, the address masking trick really does matter:
>
>    https://lore.kernel.org/all/202410161557.5b87225e-oliver.sang@intel.com/
>
> which reports that ridiculous 6.8% improvement just from avoiding the
> barrier in user_access_begin().
>
> So that barrier really *is* very expensive. Surprisingly so.

7% performance is what it costs to maintain the security barrier we were
sold originally.

Then it's a lot of time, arguing in public, and wild guesswork over
explicitly undocumented properties that the vendors would prefer not to
discuss, to try and claw some of that 7% back while keeping the security
barrier intact for the benefit of users who want it both secure and fast.

Forgive me if I think that we (the SW people) are getting the raw end of
the deal here, while vendors keep selling more and more expensive chips
that don't work safely.

~Andrew


More information about the Linuxppc-dev mailing list