On Tue, Oct 22, 2024 at 01:16:58AM -0700, Pawan Gupta wrote: > On Mon, Oct 21, 2024 at 01:48:15PM +0300, Kirill A. Shutemov wrote: > > On Sun, Oct 20, 2024 at 03:59:25PM -0700, Linus Torvalds wrote: > > > On Sun, 20 Oct 2024 at 15:44, Josh Poimboeuf <jpoim...@kernel.org> wrote: > > > > > > > > Anyway, I'd really like to make forward progress on getting rid of the > > > > LFENCEs in copy_from_user() and __get_user(), so until if/when we hear > > > > back from both vendors, how about we avoid noncanonical exceptions > > > > altogether (along with the edge cases mentioned above) and do something > > > > like the below? > > > > > > That doesn't work for LAM at _all_. > > > > > > So at a minimum, you need to then say "for LAM enabled CPU's we do the > > > 'shift sign bit' trick". > > > > > > Hopefully any LAM-capable CPU doesn't have this issue? > > > > LAM brings own speculation issues[1] that is going to be addressed by > > LASS[2]. There was a patch[3] to disable LAM until LASS is landed, but it > > never got applied for some reason. > > AIU, issue with LAM is it allows speculative translation of non-canonical > user address. It does not allow data fetches from those addresses. SLAM > attack uses LAM to form a TLB-based disclosure gadget. In essence, SLAM > needs to chain another speculative vulnerability to form a successful > attack. If the data accessed by a chained speculative vulnerability is > interpreted as a pointer, LAM may allow the translation of non-canonical > user address. This is specially true for ascii characters that have MSB > masked off.
Right. > I don't really know how this could be a problem for something like > copy_from_user() that ensures the canonicality of bit 63. It doesn't affect copy_from/to_user() and put/get_user(), but allows to make other kernel code (outside STAC/CLAC block) to speculatively translate addresses and reveal secrets this way. > AFAIK, Sierra Forest, Lunar Lake and Arrow Lake support LAM. To be on safe > side, it is better to keep LAM disabled until LASS arrives. Dave has applied it to tip/urgent. I expect it to be merged soon. -- Kiryl Shutsemau / Kirill A. Shutemov
