linux-kernel - [PATCH v2 0/3] x86: Extend LASS support to EFI configurations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260120234730.2215498-1-sohil.mehta@intel.com>
Date: Tue, 20 Jan 2026 15:47:27 -0800
From: Sohil Mehta <sohil.mehta@...el.com>
To: x86@...nel.org,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Ard Biesheuvel <ardb@...nel.org>
Cc: "H . Peter Anvin" <hpa@...or.com>,
	Andy Lutomirski <luto@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	"Kirill A . Shutemov" <kas@...nel.org>,
	Sohil Mehta <sohil.mehta@...el.com>,
	Rick Edgecombe <rick.p.edgecombe@...el.com>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	Tony Luck <tony.luck@...el.com>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	linux-kernel@...r.kernel.org,
	linux-efi@...r.kernel.org
Subject: [PATCH v2 0/3] x86: Extend LASS support to EFI configurations

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