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. I don't really know how this could be a problem for something like copy_from_user() that ensures the canonicality of bit 63. 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.
