arch/x86/kernel/cpu/common.c | 30 ++++++++++++++++++++++------- arch/x86/platform/efi/efi_64.c | 35 ++++++++++++++++++++++++++++++++++ 2 files changed, 58 insertions(+), 7 deletions(-)
Linear Address Space Separation (LASS) is currently disabled [1] when support for vsyscall emulation or EFI is compiled in. This series extends LASS support to EFI-enabled configurations. Changes in v2 ------------- - Rebased the series to v6.19-rc5 - Improved commit messages and code comments based on feedback v1: https://lore.kernel.org/lkml/20251204072143.3636863-1-sohil.mehta@intel.com/ Issues with EFI --------------- EFI boot and runtime services are incompatible with LASS because they end up accessing addresses with bit 63 cleared, which is blocked by LASS. 1) The most obvious one is the SetVirtualAddressMap() runtime service, which is expected to be called in EFI physical mode [2]. 2) Some runtime services fail to switch to virtual mode properly and continue referencing physical addresses even after SVAM. The kernel maintains a 1:1 mapping of all runtime services code and data regions to avoid breaking such firmware. 3) Some boot services code and data regions are referenced long after ExitBootServices(). Most of these access use the kernel direct map so bit 63 is expected to be set. But some odd firmware implementation could access that memory via a mapping in the lower range. Solution -------- These patches take LASS out of the path of all EFI boot and runtime service interactions by: Patch 1: Deferring LASS enabling until userspace comes up, which ensures EFI has completed switching to virtual mode and all boot services memory has been freed [3]. Patch 2: Temporarily disabling LASS every time a runtime service is executed after boot. Runtime services execute in a special efi_mm which doesn't have userspace mapped. So, the security implications of disabling LASS are fairly limited [4]. Please find more details in the respective patches. Alternate options ----------------- One option is to not support broken firmware implementations (by avoiding patch 2) starting with systems that support LASS. That would trigger #GP faults if runtime calls try to access the 1:1 mapped physical memory. Even though this is expected to be rare in modern platforms, there isn't a clear benefit of keeping LASS active during runtime calls executing under efi_mm. Also, client BIOSes typically get validated with Windows during development. So, some users could see in-field failures when they start running newer Linux kernels with LASS enabled. Though Ard suggests that things have improved on the Windows side, it doesn't seem worth taking the risk to me. In the long run, to encourage BIOSes to fix bad code, the kernel could trap invalid accesses to 1:1 mapped physical memory and then warn about buggy firmware. However, such an effort should be pursued independent of LASS [5]. Links ----- [1]: https://lore.kernel.org/lkml/20251118182911.2983253-1-sohil.mehta@intel.com/ [2]: https://uefi.org/specs/UEFI/2.10/08_Services_Runtime_Services.html#setvirtualaddressmap [3]: https://lore.kernel.org/lkml/ee2fce64-91ce-4b78-b2f9-33364ea0c52f@intel.com/ [4]: https://lore.kernel.org/lkml/F707CA45-DA37-460A-AEFF-C11AC6AB6A05@zytor.com/ [5]: https://lore.kernel.org/lkml/255724be-a6d8-4aa6-94f9-1e6ffba3a3cc@zytor.com/ Sohil Mehta (3): x86/cpu: Defer LASS enabling until userspace comes up x86/efi: Disable LASS while executing runtime services x86/cpu: Remove LASS restriction on EFI arch/x86/kernel/cpu/common.c | 30 ++++++++++++++++++++++------- arch/x86/platform/efi/efi_64.c | 35 ++++++++++++++++++++++++++++++++++ 2 files changed, 58 insertions(+), 7 deletions(-) base-commit: 0f61b1860cc3f52aef9036d7235ed1f017632193 -- 2.43.0
On Tue, Jan 20, 2026 at 03:47:27PM -0800, Sohil Mehta wrote: > Linear Address Space Separation (LASS) is currently disabled [1] when > support for vsyscall emulation or EFI is compiled in. This series > extends LASS support to EFI-enabled configurations. I tried these patches on a LASS-capable system with a kernel built with CONFIG_X86_VSYSCALL_EMULATION disabled, and traces added to efi_disable_lass() and efi_enable_lass(). System boots OK (with a bunch of my trace messages showing that CR4.LASS was disabled/enabled around EFI calls from several CPUs). Just for grins I commented out the CR4 changes from the efi_disable_lass() and efi_enable_lass(). System still boots OK, so it seems the EFI runtime calls during boot don't have any of the BIOS bugs that require LASS disable. Tested-by: Tony Luck <tony.luck@intel.com> -Tony
Booted successfully with the patches on a Sierra Forest system. Checked it out with LAM enabled and my KASAN series, and ran KASAN kunits without issues and the LAM selftests also worked as expected. Tested-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com> (resending because my email client ate the in-reply-to) On 2026-01-20 at 15:47:27 -0800, Sohil Mehta wrote: >Linear Address Space Separation (LASS) is currently disabled [1] when >support for vsyscall emulation or EFI is compiled in. This series >extends LASS support to EFI-enabled configurations. > >Changes in v2 >------------- >- Rebased the series to v6.19-rc5 >- Improved commit messages and code comments based on feedback > >v1: https://lore.kernel.org/lkml/20251204072143.3636863-1-sohil.mehta@intel.com/ > >Issues with EFI >--------------- >EFI boot and runtime services are incompatible with LASS because they >end up accessing addresses with bit 63 cleared, which is blocked by LASS. > > 1) The most obvious one is the SetVirtualAddressMap() runtime service, > which is expected to be called in EFI physical mode [2]. > > 2) Some runtime services fail to switch to virtual mode properly and > continue referencing physical addresses even after SVAM. The kernel > maintains a 1:1 mapping of all runtime services code and data regions > to avoid breaking such firmware. > > 3) Some boot services code and data regions are referenced long after > ExitBootServices(). Most of these access use the kernel direct map so > bit 63 is expected to be set. But some odd firmware implementation > could access that memory via a mapping in the lower range. > >Solution >-------- >These patches take LASS out of the path of all EFI boot and runtime >service interactions by: > > Patch 1: Deferring LASS enabling until userspace comes up, which > ensures EFI has completed switching to virtual mode and all boot > services memory has been freed [3]. > > Patch 2: Temporarily disabling LASS every time a runtime service is > executed after boot. Runtime services execute in a special efi_mm > which doesn't have userspace mapped. So, the security implications of > disabling LASS are fairly limited [4]. > >Please find more details in the respective patches. > >Alternate options >----------------- >One option is to not support broken firmware implementations (by >avoiding patch 2) starting with systems that support LASS. That would >trigger #GP faults if runtime calls try to access the 1:1 mapped >physical memory. Even though this is expected to be rare in modern >platforms, there isn't a clear benefit of keeping LASS active during >runtime calls executing under efi_mm. > >Also, client BIOSes typically get validated with Windows during >development. So, some users could see in-field failures when they start >running newer Linux kernels with LASS enabled. Though Ard suggests that >things have improved on the Windows side, it doesn't seem worth taking >the risk to me. > >In the long run, to encourage BIOSes to fix bad code, the kernel could >trap invalid accesses to 1:1 mapped physical memory and then warn about >buggy firmware. However, such an effort should be pursued independent of >LASS [5]. > >Links >----- >[1]: https://lore.kernel.org/lkml/20251118182911.2983253-1-sohil.mehta@intel.com/ >[2]: https://uefi.org/specs/UEFI/2.10/08_Services_Runtime_Services.html#setvirtualaddressmap >[3]: https://lore.kernel.org/lkml/ee2fce64-91ce-4b78-b2f9-33364ea0c52f@intel.com/ >[4]: https://lore.kernel.org/lkml/F707CA45-DA37-460A-AEFF-C11AC6AB6A05@zytor.com/ >[5]: https://lore.kernel.org/lkml/255724be-a6d8-4aa6-94f9-1e6ffba3a3cc@zytor.com/ > > >Sohil Mehta (3): > x86/cpu: Defer LASS enabling until userspace comes up > x86/efi: Disable LASS while executing runtime services > x86/cpu: Remove LASS restriction on EFI > > arch/x86/kernel/cpu/common.c | 30 ++++++++++++++++++++++------- > arch/x86/platform/efi/efi_64.c | 35 ++++++++++++++++++++++++++++++++++ > 2 files changed, 58 insertions(+), 7 deletions(-) > > >base-commit: 0f61b1860cc3f52aef9036d7235ed1f017632193 >-- >2.43.0 >
© 2016 - 2026 Red Hat, Inc.