LASS (Linear Address Space Separation)
Linear Address Space Separation prevents speculative address access across user/kernel mode.
LASS has been released by Intel as a security extension here https://cdrdv2.intel.com/v1/dl/getContent/671368 and probably getting released in the generation “Sierra Forest”
It works in 64-bit mode and partitions the address space into two halves:
- Lower half (LA[63]=0) –> user space
- Upper half (LA[63]=1) –> kernel space
If the kernel mode tries to acess lower half address, it will raise #GP(0)
. If the userspace tries to access kernel space address, it will raise it too. If the kernel needs to access userspace, it can disable LASS by disabling SMAP (Supervisor Mode Access Prevention) with stac()/clac()
.
But what’s the deal? We already have that with classical memory protection mechanisms…
Crucially, this policy is applied early in the execution of an instruction. Normal page protections can only be read (and, thus, enforced) by traversing through the page-table hierarchy, which produces timing and cache artifacts.
[…] LASS can allow some of the more expensive Meltdown and Spectre mitigations to be turned off without compromising security […]. But, for now, nobody has said publicly which mitigations, if any, are rendered unnecessary by LASS.
Problems: Legacy vsyscall
functions used by old glibc are located in range 0xffffffffff600000-0xffffffffff601000
and emulated in kernel. To comply with LASS they are disabled.
Linux implements the patch here https://lwn.net/ml/linux-kernel/20230110055204.3227669-1-yian.chen@intel.com/