News: 0001501970

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Linux 6.12-rc5 Disabling Intel's Linear Address Masking "LAM" Due To Security Concerns

([Linux Kernel] 6 Hours Ago Linear Address Masking)


[1]Intel merged Linear Address Masking into the Linux kernel last year as a means of allowing user-space to store metadata within some bits of pointers without masking it out before use. LAM can be useful for virtual machines, sanitizers / profiling / memory tagging, and other uses. While the brand new Intel Arrow Lake and Lunar Lake CPUs support LAM, the Linux kernel is now disabling LAM out of security concerns.

[2]Linear Address Masking in theory is great and can allow for some nifty features in user-space like for databases, web servers, Java, and other high level languages and for profiling and more. But besides [3]Linus Torvalds not liking Intel's "LAN" name , it's also been found to have security issues with the initial processor support.

Last week I wrote about [4]Linus Torvalds Growing Frustrated By Buggy Hardware & Theoretical CPU Attacks . As the latest on that front where Intel LAM was brought up, the patch was submitted for mainline today to go ahead and disable the Linear Address Masking feature... The patch from Intel was posted back in January but lost on the mailing list until brought up with Torvalds' recent CPU security discussions. The [5]patch explains:

"Intel feature Linear Address Masking (LAM) has a weakness related to transient execution as described in the SLAM paper. Unless Linear Address Space Separation (LASS) is enabled this weakness may be exploitable.

Until kernel adds support for LASS, only allow LAM for COMPILE_TEST, or when speculation mitigations have been disabled at compile time, otherwise keep LAM disabled."

So unless you compile your Linux kernel from source with "SPECULATION_MITIGATIONS" disabled entirely, the Linear Address Masking "ADDRESS_MASKING" support will be disabled at compile-time. Basically no making use of LAM reasonably on the Linux kernel until Linear Address Space Separation (LASS) is sorted out for preventing malicious virtual address space accesses across user/kernel mode. LASS though also requires CPU hardware-side support and so for current Arrow Lake / Lunar Lake processors the LAM support is basically worthless.

[6]

This LAM address masking disabling patch was sent out this morning as part of the [7]x86/urgent patches for the week ahead of this evening's Linux 6.12-rc5 release.



[1] https://www.phoronix.com/news/Intel-LAM-Merged-Linux-6.4

[2] https://www.phoronix.com/search/Linear+Address+Masking

[3] https://www.phoronix.com/news/Torvalds-Bashes-Intel-LAM

[4] https://www.phoronix.com/news/Torvalds-Frustrated-Buggy-HW

[5] https://lore.kernel.org/lkml/20240119162104.4ehgnj4ptjrfwyhf@windy/t/

[6] https://www.phoronix.com/image-viewer.php?id=2024&image=intel_lam_disable_lrg

[7] https://lore.kernel.org/lkml/20241027105741.GAZx4cpWYuun5QaU8K@fat_crate.local/



hf_139

hamishmb

loganj

pWe00Iri3e7Z9lHOX2Qx

skeevy420

intelfx

npwx

Trailing Edge Technologies is pleased to announce the following
TETflame programme:

1) For a negotiated price (no quatloos accepted) one of our flaming
representatives will flame the living shit out of the poster of
your choice. The price is inversely proportional to how much of
an asshole the target it. We cannot be convinced to flame Dennis
Ritchie. Matt Crawford flames are free.

2) For a negotiated price (same arrangement) the TETflame programme
is offering ``flame insurance''. Under this arrangement, if
one of our policy holders is flamed, we will cancel the offending
article and flame the flamer, to a crisp.

3) The TETflame flaming representatives include: Richard Sexton, Oleg
Kisalev, Diane Holt, Trish O'Tauma, Dave Hill, Greg Nowak and our most
recent acquisition, Keith Doyle. But all he will do is put you in his
kill file. Weemba by special arrangement.

-- Richard Sexton