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

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] [day] [month] [year] [list]

Message-ID: <fda92169-224d-45e5-8645-7f4b12fc5ba4@citrix.com>
Date: Fri, 25 Oct 2024 20:00:17 +0100
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc: x86@...nel.org, Josh Poimboeuf <jpoimboe@...nel.org>,
 Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH] x86: fix user address masking non-canonical speculation
 issue

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@...rix.com>
> Link: https://lore.kernel.org/all/80d94591-1297-4afb-b510-c665efd37f10@citrix.com/
> 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@...nel.org>
> Cc: Borislav Petkov <bp@...en8.de>
> 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@...ux-foundation.org>

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

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