Linus Torvalds Bashes Intel's LAM - Rejected For Linux 6.2

Linus Torvalds can be known for his hardware commentary at times like hoping AVX-512 "dies a painful death", Intel's "bad policies" around ECC memory, and giving NVIDIA the finger. The latest colorful commentary by the Linux creator is around Intel's new Linear Address Masking (LAM) feature that aimed to land in Linux 6.2 but is now delayed until the code can be reworked.

Linear Address Masking is a feature Intel originally detailed in 2020 and their engineers have been working on the Linux kernel enablement since and had sent it in for merging with Linux 6.2, albeit that is no longer happening.

Intel PRM documentation on this new hardware feature has been available since 2020.

Simply put, Intel LAM is about using the untranslated address bits of user-space addresses so it can be used for metadata. LAM can be used for a variety of purposes with the metadata like user-space memory sanitizers and tagging and is similar in nature to AMD's Upper Address Ignore "UAI" with Zen 4 and Arm's Top Byte Ignore "TBI" features. It's believed that LAM will first be found in Intel Sapphire Rapids processors.

Linus Torvalds isn't happy though with the Linux LAM kernel implementation and even the name, The LAM kernel enablement was sent in as part of the x86/mm changes for Linux 6.2. But in response to that Torvalds wrote:

Christ.

Is it too late to ask Intel to call this "Top-Bits-Ignore", and instead of adding another crazy TLA [Three Letter Acronym], we'd just all agree to call this "TBI"?

I know, I know, NIH and all that, but at least as long as we are limiting ourselves to regular US-ASCII, we really only have 17576 TLA's to go around, and at some point it gets not only confusing, but really quite wasteful, to have everybody make up their own architecture-specific TLA.

And while I'm on the subject: I really think that the changes to "untagged_addr()" are fundamentally broken.

Why? That whole LAM (or BTI) is not necessarily per-mm. It can easily be per-*thread*.

Imagine, if you will, a setup where you have some threads that use tagged pointers, and some threads that don't.

For example, maybe the upper bits of the address contains a tag that is used only used within a virtual machine? You could even have the "native" mode use the full address space, and put itself and its private data in the upper bits virtually.

[In other words], imagine using the virtual address masking as not just memory sanitizers, but as an actual honest-to-goodness separation feature (eg JITed code might fundamentally have access only to the lower bits, while the JITter itself sees the whole address space).

Maybe that's not how LAM works on x86, but your changes to untagged_addr() are *not* x86-specific.

So I really think this is completely wrong, quite aside from the naming. It just makes assumptions that aren't valid.

The fact that you made this mm-specific actually ends up being an active bug in the code, even on x86-64. You use the mmap lock to serialize this all in prctl_enable_tagged_addr(), but then the read side (ie just untagged_addr()) isn't actually serialized at all - and *shouldn't* be serialized.

So I really think this is a fundamental design mistake, and while I pulled it and sorted out the trivial conflicts, I've unpulled it again as being actively mis-designed.

A Linux kernel mailing list discussion then ensued over possible design changes to how Intel's Linear Address Masking is implemented for the Linux. But long story short, Torvalds views the Intel LAM code as not ready for Linux and didn't end up pulling the code. It's over the software enablement that strikes the wrong chord with him and not the hardware feature itself.

Intel LAM isn't landing for Linux 6.2 with Torvalds being unhappy over the kernel implementation and is of the opinion that some of the kernel changes for supporting it are "fundamentally broken"... In an ideal world, he'd also prefer it be re-branded.

A new x86/mm pull has now been submitted but with the LAM enablement removed. Intel Linux engineers are going to rework the LAM code and hope to have that reworked implementation ready for Linux 6.3 in a form that will make Linus Torvalds happier than this proposed code.