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

Message-ID: <99d67545-8dfb-4987-b723-47ca5b0512a7@citrix.com>
Date: Fri, 25 Oct 2024 19:52:12 +0100
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>,
 Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, x86@...nel.org,
 Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH] x86: fix user address masking non-canonical speculation
 issue

On 24/10/2024 7:47 pm, Josh Poimboeuf wrote:
> On Thu, Oct 24, 2024 at 10:35:33AM -0700, Linus Torvalds wrote:
>>>  i.e. when bit 47/56 is
>>> set and 63 is cleared, would it not go untouched by mask_user_address()
>>> and thus be speculatively interpreted by AMD as a kernel address?
>> AMD doesn't _have_ LAM. When they do, they had better not
>> speculatively mis-interpret addresses.
> Ok.  I was thinking AMD had its own version of LAM, though all I can
> find is UAI which is actually quite different since it ignores bit 63
> altogether (and isn't supported in Linux anyway).

Yes, UAI is AMD's offering to parallel LAM.

Perhaps the funniest aspect of UAI is that it intentionally doesn't
apply (i.e. no ignoring) for stack-relative accesses.

Now consider what happens when frame pointers are turned off and the
compiler is free to use %rbp for other things...

And then realise that you can fix this mess in 32bit with an explicit
%ds segment override, but you can't in 64bit.

In 64bit mode, most segments prefixes are ignored and %ds does not
override the default-%ss-ness of %rbp/%rsp-relative accesses.

~Andrew