On Mon, Oct 28, 2024 at 06:07:48PM +0200, Alexander Shishkin wrote: > Linear Address Space Separation (LASS) is a security feature that intends to > prevent malicious virtual address space accesses across user/kernel mode. > > Such mode based access protection already exists today with paging and features > such as SMEP and SMAP. However, to enforce these protections, the processor > must traverse the paging structures in memory. Malicious software can use > timing information resulting from this traversal to determine details about the > paging structures, and these details may also be used to determine the layout > of the kernel memory. > > The LASS mechanism provides the same mode-based protections as paging but > without traversing the paging structures. Because the protections enforced by > LASS are applied before paging, software will not be able to derive > paging-based timing information from the various caching structures such as the > TLBs, mid-level caches, page walker, data caches, etc. LASS can avoid probing > using double page faults, TLB flush and reload, and SW prefetch instructions. > See [2], [3] and [4] for some research on the related attack vectors. > > In addition, LASS prevents an attack vector described in a Spectre LAM (SLAM) > whitepaper [7]. > > LASS enforcement relies on the typical kernel implemetation to divide the > 64-bit virtual address space into two halves: > Addr[63]=0 -> User address space > Addr[63]=1 -> Kernel address space > Any data access or code execution across address spaces typically results in a > #GP fault. > > Kernel accesses usually only happen to the kernel address space. However, there > are valid reasons for kernel to access memory in the user half. For these cases > (such as text poking and EFI runtime accesses), the kernel can temporarily > suspend the enforcement of LASS by toggling SMAP (Supervisor Mode Access > Prevention) using the stac()/clac() instructions and in one instance a downright > disabling LASS for an EFI runtime call. > > User space cannot access any kernel address while LASS is enabled. > Unfortunately, legacy vsyscall functions are located in the address range > 0xffffffffff600000 - 0xffffffffff601000 and emulated in kernel. To avoid > breaking user applications when LASS is enabled, extend the vsyscall emulation > in execute (XONLY) mode to the #GP fault handler. > > In contrast, the vsyscall EMULATE mode is deprecated and not expected to be > used by anyone. Supporting EMULATE mode with LASS would need complex > intruction decoding in the #GP fault handler and is probably not worth the > hassle. Disable LASS in this rare case when someone absolutely needs and > enables vsyscall=emulate via the command line. I lack the wit to read & understand these patches to answer this question, so I'll just ask it: What happens when the kernel does a NULL pointer dereference (due to a bug)? It's not an attempt to access userspace, but it should result in a good bug report. Normally this would be outside a STAC/CLAC region, but I suppose technically it could be within one.
