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: <20241024184744.l3575coe4sx26hgl@treble.attlocal.net>
Date: Thu, 24 Oct 2024 11:47:44 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	x86@...nel.org, Andrew Cooper <andrew.cooper3@...rix.com>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH] x86: fix user address masking non-canonical speculation
 issue

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).

> > Also, the comment above __access_ok() now seems obsolete:
> >
> > /*
> >  * User pointers can have tag bits on x86-64.  This scheme tolerates
> >  * arbitrary values in those bits rather then masking them off.
> 
> No. The comment is still correct. The scheme tolerates exactly the LAM
> kind of hardware-based address masking.

The comment doesn't seem right to me at all.

With LAM enabled, USER_PTR_MAX is PAGE_SIZE away from the sign change
boundary.  So __access_ok() no longer has size check slop and that whole
discussion about the sign change boundary can go away.

AFAICT #GP can only happen when LAM is enabled and bit 47 (or 56 for
LA57) doesn't match bit 63.

-- 
Josh