Intel Posts Linux Patches For Linear Address Space Separation (LASS)

[phoronix]

Phoronix: Intel Posts Linux Patches For Linear Address Space Separation (LASS)

An interesting patch series posted by Intel this week for the Linux kernel is working on implementing Linear Address Space Separation (LASS) as a feature coming with future processors to help fend off speculative address accesses across..

https://www.phoronix.com/news/Linear-Address-Space-Separation

[Mahboi]

Poor title, should've gone with "Intel saves thousands of Linux users' sanity by finally giving them a LASS"

[brucethemoose]

Well that seems very sensible, especially if the kernel-side implementation is so simple.

I assume the boundry will move as more kernel space is allocated/released? Or is kernel space's memory requirement relatively static?

[Spacefish]

Well that seems very sensible, especially if the kernel-side implementation is so simple.

I assume the boundry will move as more kernel space is allocated/released? Or is kernel space's memory requirement relatively static?

Nah, you have 63bit left (less than that due too NX-Flag and such), but typical system don´t use this at all.. Physical addresses aren´t 1:1 mapped to address lines on hardware.. There aren´t even 64 individual address lines to the memory / from the CPU, the socket as no system supports that much real memory.

63bit still gives you 8 Exabyte of addressable memory with a 8bit wordlength.

If we every reach this level, the right way to do is to go to 128bit, there are different models availiable for that already.. Some just implement some sort of "bankswitch" instructions where you have in instruction to tell the CPU which 64bit address space in your real address space you want to use. Other models use native 128bit pointers.

[kylew77]

Nah, you have 63bit left (less than that due too NX-Flag and such), but typical system don´t use this at all.. Physical addresses aren´t 1:1 mapped to address lines on hardware.. There aren´t even 64 individual address lines to the memory / from the CPU, the socket as no system supports that much real memory.

63bit still gives you 8 Exabyte of addressable memory with a 8bit wordlength.

If we every reach this level, the right way to do is to go to 128bit, there are different models availiable for that already.. Some just implement some sort of "bankswitch" instructions where you have in instruction to tell the CPU which 64bit address space in your real address space you want to use. Other models use native 128bit pointers.

Noob question here, would going to 128bit computing give us the same speed benefits but memory growth that 32bit to 64bit brought?

[pthariensflame]

Possibly worth noting that 64-bit Arm processors already have this feature as of at least a year ago in silicon and multiple in documentation. They call it EL0 Permission Deny (FEAT_E0PD), building on Privileged Access Never (FEAT_PAN, FEAT_PAN2, FEAT_PAN3), and it’s actually more flexible than LASS and SMAP, allowing you to selectively lock off only userspace from kernelspace, or only vice versa, or both, and allowing you to select whether instruction fetches are included in the ban or not, and decide which side of the address space is which freely.

[erniv2]

Noob question here, would going to 128bit computing give us the same speed benefits but memory growth that 32bit to 64bit brought?

The increased bitmap only increases the theoretical ram limit not the speed that is still determined by the real physical stuff and the ordering.

32bit was limited to 4095mb but you cant use it all you need a pci address space wich limited the real usable ram with a 32 bit system to 3500mb, then you needed a kernel space where the mm operates wich limited the actual process size for userspace apps to 2048mb, a 64bit system can adress 16exabite, there is no speed benifit but alot more address space.

And 128bit mm code would mean.

"340,282,366,920,938,463,463,374,607,431,768,211,4 5 6 (corrected)

vs 64 bits:

18,446,744,073,709,551,616

So, yeah, that would be like killing a fly with a tactical nuke—overkill doesn’t even begin to describe it!" copy pasted it ~~

The speed comes from the ordering of the chips on your ram and the width the cpu can access, tricks are allready used nowdays like dual chanel ddr4 or quadchanel 64x2, but it has nothing to do with the internal OS order of things, hardware -> software, so no there will be no 128bit cpu soon, and no 128bt adress space OS it´s not needed and it does not provide speed benefits.

We all know that 64bit actually cause more ram useage, wich is handled by more caches and transistors thrown that way.

[uxmkt]

Physical addresses aren´t 1:1 mapped to address lines on hardware.. There aren´t even 64 individual address lines to the memory / from the CPU

There should be 64 lines on sparc64, and there may be other 64-bit platforms of the 90s that did. Yeah, not quite relevant for a change to x86_64, but you spoke generically, so this is the reponse.

[brucethemoose]

Possibly worth noting that 64-bit Arm processors already have this feature as of at least a year ago in silicon and multiple in documentation. They call it EL0 Permission Deny (FEAT_E0PD), building on Privileged Access Never (FEAT_PAN, FEAT_PAN2, FEAT_PAN3), and it’s actually more flexible than LASS and SMAP, allowing you to selectively lock off only userspace from kernelspace, or only vice versa, or both, and allowing you to select whether instruction fetches are included in the ban or not, and decide which side of the address space is which freely.

Neat! Is it standard in ARMv9?

I keep finding all sorts of very useful things that are now being standardized in v9. It seems like one heck of a step, with perhaps the biggest ommision being matrix stuff that is getting added in later.

[tildearrow]

Phoronix: Intel Posts Linux Patches For Linear Address Space Separation (LASS)

An interesting patch series posted by Intel this week for the Linux kernel is working on implementing Linear Address Space Separation (LASS) as a feature coming with future processors to help fend off speculative address accesses across..

https://www.phoronix.com/news/Linear...ace-Separation

It appears that an accidental new line cut out the short description of