From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Josh Poimboeuf <jpoimboe@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
x86@kernel.org, Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH] x86: fix user address masking non-canonical speculation issue
Date: Fri, 25 Oct 2024 19:52:12 +0100 [thread overview]
Message-ID: <99d67545-8dfb-4987-b723-47ca5b0512a7@citrix.com> (raw)
In-Reply-To: <20241024184744.l3575coe4sx26hgl@treble.attlocal.net>
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
next prev parent reply other threads:[~2024-10-25 18:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-24 1:31 Linus Torvalds
2024-10-24 6:13 ` Josh Poimboeuf
2024-10-24 14:02 ` Kirill A. Shutemov
2024-10-24 15:42 ` Josh Poimboeuf
2024-10-24 17:35 ` Linus Torvalds
2024-10-24 18:47 ` Josh Poimboeuf
2024-10-25 18:52 ` Andrew Cooper [this message]
2024-10-25 9:01 ` Kirill A. Shutemov
2024-10-24 11:08 ` Borislav Petkov
2024-10-24 12:32 ` Kirill A. Shutemov
2024-10-24 13:02 ` Borislav Petkov
2024-10-24 17:53 ` Linus Torvalds
2024-10-24 18:13 ` Linus Torvalds
2024-10-24 19:09 ` Josh Poimboeuf
2024-10-24 20:00 ` Linus Torvalds
2024-10-25 11:24 ` Borislav Petkov
2024-10-24 14:09 ` Kirill A. Shutemov
2024-10-25 14:15 ` Maciej Wieczor-Retman
2024-10-25 17:41 ` Linus Torvalds
2024-10-25 19:00 ` Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=99d67545-8dfb-4987-b723-47ca5b0512a7@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®