Re: [PATCH] x86: fix user address masking non-canonical speculation issue

[Andrew Cooper]

On 24/10/2024 2:31 am, Linus Torvalds wrote:
> It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical
> accesses in kernel space.  And so using just the high bit to decide
> whether an access is in user space or kernel space ends up with the good
> old "leak speculative data" if you have the right gadget using the
> result:
>
>   CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“
>
> Now, the kernel surrounds the access with a STAC/CLAC pair, and those
> instructions end up serializing execution on older Zen architectures,
> which closes the speculation window.
>
> But that was true only up until Zen 5, which renames the AC bit [1].
> That improves performance of STAC/CLAC a lot, but also means that the
> speculation window is now open.
>
> Note that this affects not just the new address masking, but also the
> regular valid_user_address() check used by access_ok(), and the asm
> version of the sign bit check in the get_user() helpers.
>
> It does not affect put_user() or clear_user() variants, since there's no
> speculative result to be used in a gadget for those operations.
>
> Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Link: https://lore.kernel.org/all/80d94591-1297-4afb-b510-c665efd37f10@xxxxxxxxxx/
> Link: https://lore.kernel.org/all/20241023094448.GAZxjFkEOOF_DM83TQ@fat_crate.local/ [1]
> Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1010.html
> Link: https://arxiv.org/pdf/2108.10771
> Cc: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
> Cc: Borislav Petkov <bp@xxxxxxxxx>
> Fixes: 2865baf54077 ("x86: support user address masking instead of non-speculative conditional")
> Fixes: 6014bc27561f ("x86-64: make access_ok() independent of LAM")
> Fixes: b19b74bc99b1 ("x86/mm: Rework address range check in get_user() and put_user()")
> Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>

Thankyou.  This looks a whole lot safer than the prior options.

Tentatively Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, but
it's probably worth trying to get AMD to rubber stamp it too.