Re: [PATCH v2 0/3] x86: Extend LASS support to EFI configurations

[Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>]

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
>