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

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

[Sohil Mehta]

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.

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) Boot services code and data are referenced long after
  ExitBootServices(). For example, efi_check_for_embedded_firmwares()
  accesses boot services memory even after SetVirtualAddressMap().

  3) Some runtime services fail to switch to virtual mode properly and
  continue referencing physical addresses [3]. The kernel maintains a
  1:1 mapping of all runtime services code and data regions to avoid
  breaking such firmware.

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 [4]. 

  Patch 2: Temporarily disabling LASS every time a runtime service is
  executed after boot [5].

Please find more details in the respective patches.

Alternate options
-----------------
One option is to not support broken firmware implementations with LASS
by avoiding patch 2. That would trigger #GP faults when runtime calls
try to access the 1:1 mapped physical memory. However, most client
BIOSes typically get validated with Windows during development [3]. So,
some users could see in-field failures when they start running newer
Linux kernels with LASS enabled. 

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 [6].

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/CAMj1kXGyTo=4Va1PevMQyCauEKSutfSPo6je0Ps09TabhTe4zQ@mail.gmail.com/
[4]: https://lore.kernel.org/lkml/ee2fce64-91ce-4b78-b2f9-33364ea0c52f@intel.com/
[5]: https://lore.kernel.org/lkml/6ab6e4d3-0caa-41e6-8231-2f3f45949876@intel.com/
[6]: 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: Make runtime services compatible with LASS
  x86/cpu: Remove LASS restriction on EFI

 arch/x86/kernel/cpu/common.c   | 24 +++++++++++++++++-------
 arch/x86/platform/efi/efi_64.c | 31 +++++++++++++++++++++++++++++++
 2 files changed, 48 insertions(+), 7 deletions(-)


base-commit: d61f1cc5db799f4e44a63418b2dc19396787427b
-- 
2.43.0

[PATCH 1/3] x86/cpu: Defer LASS enabling until userspace comes up

[Sohil Mehta]

LASS blocks any kernel access to the lower half of the virtual address
space. Unfortunately, some EFI accesses happen during boot with bit 63
cleared, which causes a #GP fault when LASS is enabled.

Notably, the SetVirtualAddressMap() call can only happen in EFI physical
mode. Also, EFI_BOOT_SERVICES_CODE/_DATA could be accessed even after
ExitBootServices(). For example, efi_check_for_embedded_firmwares()
accesses this memory even after SetVirtualAddressMap().

At a minimum, LASS enabling must be deferred until EFI has completely
finished entering virtual mode (including freeing boot services memory).
Moving setup_lass() to arch_cpu_finalize_init() would do the trick, but
it would make the implementation fragile. Something else might come in
the future that needs the LASS enabling to be moved again.

In general, security features such as LASS provide limited value before
userspace is up. They aren't necessary during early boot while only
trusted ring0 code is executing. Introduce a generic late initcall to
defer activating some CPU features until userspace is enabled.

For now, only move the LASS CR4 programming to this initcall. As APs are
already up by the time late initcalls run, some extra steps are needed
to enable LASS on all CPUs. Use a CPU hotplug callback instead of
on_each_cpu() or smp_call_function(). This ensures that LASS is enabled
on every CPU that is currently online as well as any future CPUs that
come online later. Note, even though hotplug callbacks run with
preemption enabled, cr4_set_bits() would disable interrupts while
updating CR4.

Keep the existing logic in place to clear the LASS feature bits early.
setup_clear_cpu_cap() must be called before boot_cpu_data is finalized
and alternatives are patched. Eventually, the entire setup_lass() logic
can go away once the restrictions based on vsyscall emulation and EFI
are removed.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
 arch/x86/kernel/cpu/common.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index e7ab22fce3b5..c6835a04d734 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -422,12 +422,27 @@ static __always_inline void setup_lass(struct cpuinfo_x86 *c)
 	if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION) ||
 	    IS_ENABLED(CONFIG_EFI)) {
 		setup_clear_cpu_cap(X86_FEATURE_LASS);
-		return;
 	}
+}
 
+static int enable_lass(unsigned int cpu)
+{
 	cr4_set_bits(X86_CR4_LASS);
+
+	return 0;
 }
 
+static int cpu_finalize_pre_userspace(void)
+{
+	if (!cpu_feature_enabled(X86_FEATURE_LASS))
+		return 0;
+
+	cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/lass:enable", enable_lass, NULL);
+
+	return 0;
+}
+late_initcall(cpu_finalize_pre_userspace);
+
 /* These bits should not change their value after CPU init is finished. */
 static const unsigned long cr4_pinned_mask = X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP |
 					     X86_CR4_FSGSBASE | X86_CR4_CET | X86_CR4_FRED;
-- 
2.43.0

[PATCH 2/3] x86/efi: Make runtime services compatible with LASS

[Sohil Mehta]

Ideally, EFI runtime services should switch to kernel virtual addresses
after SetVirtualAddressMap(). However, firmware implementations are
known to be buggy in this regard and continue to access physical
addresses. The kernel maintains a 1:1 mapping of all runtime services
code and data regions to avoid breaking such firmware.

LASS enforcement relies on bit 63 of the virtual address, which would
block such accesses to the lower half. Unfortunately, not doing anything
could lead to #GP faults when users update to a kernel with LASS
enabled.

One option is to use a STAC/CLAC pair to temporarily disable LASS data
enforcement. However, there is no guarantee that the stray accesses
would only touch data and not perform instruction fetches. Also, relying
on the AC bit would depend on the runtime calls preserving RFLAGS, which
is highly unlikely in practice.

Instead, use the big hammer and switch off the entire LASS mechanism
temporarily by clearing CR4.LASS. Do this right after switching to
efi_mm (as userspace is not mapped) to minimize the security impact.

Some runtime services can be invoked during boot when LASS isn't active.
Use a global variable (similar to efi_mm) to save and restore the
correct CR4.LASS state. The runtime calls are serialized with the
efi_runtime_lock, so no concurrency issues are expected.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
 arch/x86/platform/efi/efi_64.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index b4409df2105a..3d0593d6d54c 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -55,6 +55,7 @@
  */
 static u64 efi_va = EFI_VA_START;
 static struct mm_struct *efi_prev_mm;
+static unsigned long efi_cr4_lass;
 
 /*
  * We need our own copy of the higher levels of the page tables
@@ -443,16 +444,46 @@ static void efi_leave_mm(void)
 	unuse_temporary_mm(efi_prev_mm);
 }
 
+/*
+ * Toggle LASS to allow EFI to access any 1:1 mapped region in the lower
+ * half.
+ *
+ * Disable LASS after switching to EFI-mm, as userspace is not mapped in
+ * it. Similar to EFI-mm, they rely on preemption being disabled and the
+ * calls being serialized.
+ */
+
+static void efi_disable_lass(void)
+{
+	if (!cpu_feature_enabled(X86_FEATURE_LASS))
+		return;
+
+	/* Save current CR4.LASS state */
+	efi_cr4_lass = cr4_read_shadow() & X86_CR4_LASS;
+	cr4_clear_bits(efi_cr4_lass);
+}
+
+static void efi_enable_lass(void)
+{
+	if (!cpu_feature_enabled(X86_FEATURE_LASS))
+		return;
+
+	/* Reprogram CR4.LASS only if it was set earlier */
+	cr4_set_bits(efi_cr4_lass);
+}
+
 void arch_efi_call_virt_setup(void)
 {
 	efi_sync_low_kernel_mappings();
 	efi_fpu_begin();
 	firmware_restrict_branch_speculation_start();
 	efi_enter_mm();
+	efi_disable_lass();
 }
 
 void arch_efi_call_virt_teardown(void)
 {
+	efi_enable_lass();
 	efi_leave_mm();
 	firmware_restrict_branch_speculation_end();
 	efi_fpu_end();
-- 
2.43.0

[PATCH 3/3] x86/cpu: Remove LASS restriction on EFI

[Sohil Mehta]

The initial LASS enabling has been deferred to much later during boot,
and EFI runtime services now run with LASS temporarily disabled. This
removes LASS from the path of all EFI services.

To make LASS more usable, remove the restriction on EFI, as the two can
now coexist.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
 arch/x86/kernel/cpu/common.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c6835a04d734..9c60084203b5 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -415,14 +415,9 @@ static __always_inline void setup_lass(struct cpuinfo_x86 *c)
 	 * Legacy vsyscall page access causes a #GP when LASS is active.
 	 * Disable LASS because the #GP handler doesn't support vsyscall
 	 * emulation.
-	 *
-	 * Also disable LASS when running under EFI, as some runtime and
-	 * boot services rely on 1:1 mappings in the lower half.
 	 */
-	if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION) ||
-	    IS_ENABLED(CONFIG_EFI)) {
+	if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION))
 		setup_clear_cpu_cap(X86_FEATURE_LASS);
-	}
 }
 
 static int enable_lass(unsigned int cpu)
-- 
2.43.0

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

[Ard Biesheuvel]

Hello Sohil,

On Thu, 4 Dec 2025 at 08:23, Sohil Mehta <sohil.mehta@intel.com> 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.
>
> 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) Boot services code and data are referenced long after
>   ExitBootServices(). For example, efi_check_for_embedded_firmwares()
>   accesses boot services memory even after SetVirtualAddressMap().
>

These accesses use the kernel direct map, so I don't think they come
into play here.

>   3) Some runtime services fail to switch to virtual mode properly and
>   continue referencing physical addresses [3]. The kernel maintains a
>   1:1 mapping of all runtime services code and data regions to avoid
>   breaking such firmware.
>

In [3], I mainly elaborated on why it is still necessary to call
SetVirtualAddressMap(), and why it needs to be called with a mapping
in the upper address range.

For this particular call, there is no choice but to disarm LASS, given
that the lower mapping is still active at this point.

However, that does not imply that we have to assume that systems that
support LASS (which are fairly recent AIUI) are buggy in the same way,
i.e., that they access addresses in the 1:1 region after
SetVirtualAddressMap() completes.

In fact, we might attempt to use the availability of LASS as a
preliminary cutoff point for disabling this hack entirely, and only
backpedal if we get actual reports where this is still a problem. Note
that even if it is true that many PC vendors typically only test their
systems with Windows, its security posture has improved considerably
in recent years, and I wouldn't be surprised if such firmware bugs now
cause problems with Windows as well.

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

[Sohil Mehta]

On 12/4/2025 4:47 AM, Ard Biesheuvel wrote:
> Hello Sohil,
> 

Hello Ard - Thank you for looking at the patches.


>>
>>   2) Boot services code and data are referenced long after
>>   ExitBootServices(). For example, efi_check_for_embedded_firmwares()
>>   accesses boot services memory even after SetVirtualAddressMap().
>>
> 
> These accesses use the kernel direct map, so I don't think they come
> into play here.
> 

I don't mean SVAM should have switched these addresses to virtual ones
but doesn't all of EFI_BOOT_SERVICES_{CODE|DATA} have address[63] = 0?

LASS wouldn't care whether there is an actual mapping behind the
address. It only relies on the MSB for enforcement. So, any code that
relied on accessing boot services memory before efi_free_boot_services()
could get affected by LASS.

Or, did I misunderstand your comment? I am trying to clarify because I
have similar wording in the commit messages, and it would be preferable
to keep that accurate.

>>   3) Some runtime services fail to switch to virtual mode properly and
>>   continue referencing physical addresses [3]. The kernel maintains a
>>   1:1 mapping of all runtime services code and data regions to avoid
>>   breaking such firmware.
>>
> 
> In [3], I mainly elaborated on why it is still necessary to call
> SetVirtualAddressMap(), and why it needs to be called with a mapping
> in the upper address range.
> 
> For this particular call, there is no choice but to disarm LASS, given
> that the lower mapping is still active at this point.
> 
> However, that does not imply that we have to assume that systems that
> support LASS (which are fairly recent AIUI) are buggy in the same way,
> i.e., that they access addresses in the 1:1 region after
> SetVirtualAddressMap() completes.

I assumed that it must be widespread because the kernel maintains the
1:1 mapping unconditionally without any Family-model checks. The code
isn't explicitly warning about such implementations, either.

> 
> In fact, we might attempt to use the availability of LASS as a
> preliminary cutoff point for disabling this hack entirely, and only
> backpedal if we get actual reports where this is still a problem. 

Sure, I am onboard with this approach, but some folks seemed skeptical
about it during the base LASS series review. My only concern is breaking
user systems when they update to a LASS-enabled kernel.

x86 maintainers, any preference?

Would it be useful to put this (patch 2) behind an "efi=disable_lass"
command line option? That way, if someone runs into it, there is at
least a fallback option they can rely on. By default, we would still
expect newer firmware to not need this hack.

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

[Ard Biesheuvel]

On Thu, 4 Dec 2025 at 18:34, Sohil Mehta <sohil.mehta@intel.com> wrote:
>
> On 12/4/2025 4:47 AM, Ard Biesheuvel wrote:
> > Hello Sohil,
> >
>
> Hello Ard - Thank you for looking at the patches.
>
>
> >>
> >>   2) Boot services code and data are referenced long after
> >>   ExitBootServices(). For example, efi_check_for_embedded_firmwares()
> >>   accesses boot services memory even after SetVirtualAddressMap().
> >>
> >
> > These accesses use the kernel direct map, so I don't think they come
> > into play here.
> >
>
> I don't mean SVAM should have switched these addresses to virtual ones
> but doesn't all of EFI_BOOT_SERVICES_{CODE|DATA} have address[63] = 0?
>

Whether a mapping has bit 63 set or cleared depends on the location of
the mapping in the virtual address space, not on the location of the
physical backing of that mapping.

efi_check_for_embedded_firmwares() maps EFI_BOOT_SERVICES_DATA regions
in the kernel region, so bit 63 will be set.

> LASS wouldn't care whether there is an actual mapping behind the
> address. It only relies on the MSB for enforcement. So, any code that
> relied on accessing boot services memory before efi_free_boot_services()
> could get affected by LASS.
>

This only applies to code that accesses boot services memory via a
mapping in the lower range.

> >>   3) Some runtime services fail to switch to virtual mode properly and
> >>   continue referencing physical addresses [3]. The kernel maintains a
> >>   1:1 mapping of all runtime services code and data regions to avoid
> >>   breaking such firmware.
> >>
> >
> > In [3], I mainly elaborated on why it is still necessary to call
> > SetVirtualAddressMap(), and why it needs to be called with a mapping
> > in the upper address range.
> >
> > For this particular call, there is no choice but to disarm LASS, given
> > that the lower mapping is still active at this point.
> >
> > However, that does not imply that we have to assume that systems that
> > support LASS (which are fairly recent AIUI) are buggy in the same way,
> > i.e., that they access addresses in the 1:1 region after
> > SetVirtualAddressMap() completes.
>
> I assumed that it must be widespread because the kernel maintains the
> 1:1 mapping unconditionally without any Family-model checks. The code
> isn't explicitly warning about such implementations, either.
>

Exactly, and this is an oversight that occured 10+ years ago. No
reason to keep carrying that forward forever.

> >
> > In fact, we might attempt to use the availability of LASS as a
> > preliminary cutoff point for disabling this hack entirely, and only
> > backpedal if we get actual reports where this is still a problem.
>
> Sure, I am onboard with this approach, but some folks seemed skeptical
> about it during the base LASS series review. My only concern is breaking
> user systems when they update to a LASS-enabled kernel.
>
> x86 maintainers, any preference?
>
> Would it be useful to put this (patch 2) behind an "efi=disable_lass"
> command line option? That way, if someone runs into it, there is at
> least a fallback option they can rely on. By default, we would still
> expect newer firmware to not need this hack.
>

efi=noruntime is already available, which may be sufficient to work
around this in individual cases, to regain access to a non-booting
system.

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

[H. Peter Anvin]

On December 4, 2025 11:03:52 AM PST, Ard Biesheuvel <ardb@kernel.org> wrote:
>On Thu, 4 Dec 2025 at 18:34, Sohil Mehta <sohil.mehta@intel.com> wrote:
>>
>> On 12/4/2025 4:47 AM, Ard Biesheuvel wrote:
>> > Hello Sohil,
>> >
>>
>> Hello Ard - Thank you for looking at the patches.
>>
>>
>> >>
>> >>   2) Boot services code and data are referenced long after
>> >>   ExitBootServices(). For example, efi_check_for_embedded_firmwares()
>> >>   accesses boot services memory even after SetVirtualAddressMap().
>> >>
>> >
>> > These accesses use the kernel direct map, so I don't think they come
>> > into play here.
>> >
>>
>> I don't mean SVAM should have switched these addresses to virtual ones
>> but doesn't all of EFI_BOOT_SERVICES_{CODE|DATA} have address[63] = 0?
>>
>
>Whether a mapping has bit 63 set or cleared depends on the location of
>the mapping in the virtual address space, not on the location of the
>physical backing of that mapping.
>
>efi_check_for_embedded_firmwares() maps EFI_BOOT_SERVICES_DATA regions
>in the kernel region, so bit 63 will be set.
>
>> LASS wouldn't care whether there is an actual mapping behind the
>> address. It only relies on the MSB for enforcement. So, any code that
>> relied on accessing boot services memory before efi_free_boot_services()
>> could get affected by LASS.
>>
>
>This only applies to code that accesses boot services memory via a
>mapping in the lower range.
>
>> >>   3) Some runtime services fail to switch to virtual mode properly and
>> >>   continue referencing physical addresses [3]. The kernel maintains a
>> >>   1:1 mapping of all runtime services code and data regions to avoid
>> >>   breaking such firmware.
>> >>
>> >
>> > In [3], I mainly elaborated on why it is still necessary to call
>> > SetVirtualAddressMap(), and why it needs to be called with a mapping
>> > in the upper address range.
>> >
>> > For this particular call, there is no choice but to disarm LASS, given
>> > that the lower mapping is still active at this point.
>> >
>> > However, that does not imply that we have to assume that systems that
>> > support LASS (which are fairly recent AIUI) are buggy in the same way,
>> > i.e., that they access addresses in the 1:1 region after
>> > SetVirtualAddressMap() completes.
>>
>> I assumed that it must be widespread because the kernel maintains the
>> 1:1 mapping unconditionally without any Family-model checks. The code
>> isn't explicitly warning about such implementations, either.
>>
>
>Exactly, and this is an oversight that occured 10+ years ago. No
>reason to keep carrying that forward forever.
>
>> >
>> > In fact, we might attempt to use the availability of LASS as a
>> > preliminary cutoff point for disabling this hack entirely, and only
>> > backpedal if we get actual reports where this is still a problem.
>>
>> Sure, I am onboard with this approach, but some folks seemed skeptical
>> about it during the base LASS series review. My only concern is breaking
>> user systems when they update to a LASS-enabled kernel.
>>
>> x86 maintainers, any preference?
>>
>> Would it be useful to put this (patch 2) behind an "efi=disable_lass"
>> command line option? That way, if someone runs into it, there is at
>> least a fallback option they can rely on. By default, we would still
>> expect newer firmware to not need this hack.
>>
>
>efi=noruntime is already available, which may be sufficient to work
>around this in individual cases, to regain access to a non-booting
>system.

You are missing something *really* important:

What do you expect to gain? 

There is basically no downside to the current workaround, which is why it is unconditional.

All it takes is the BIOS developer missing to register *one* pointer and this problem is back. 

The *real* bug is the BIOSes that not only require the use of SetVirtualMap() in the first place, but require a non-1:1 mapping in the upper half. For Linux it would be far better to *only* have the restricted 1:1 mapping in the lower address space, as it wouldn't molest the kernel address layout which affects, especially, kexec.

It is high risk and low – possibly even negative – payoff to "fix" it.

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

[Ard Biesheuvel]

On Thu, 4 Dec 2025 at 20:16, H. Peter Anvin <hpa@zytor.com> wrote:
>
> On December 4, 2025 11:03:52 AM PST, Ard Biesheuvel <ardb@kernel.org> wrote:
> >On Thu, 4 Dec 2025 at 18:34, Sohil Mehta <sohil.mehta@intel.com> wrote:
> >>
> >> On 12/4/2025 4:47 AM, Ard Biesheuvel wrote:
> >> > Hello Sohil,
> >> >
> >>
> >> Hello Ard - Thank you for looking at the patches.
> >>
> >>
> >> >>
> >> >>   2) Boot services code and data are referenced long after
> >> >>   ExitBootServices(). For example, efi_check_for_embedded_firmwares()
> >> >>   accesses boot services memory even after SetVirtualAddressMap().
> >> >>
> >> >
> >> > These accesses use the kernel direct map, so I don't think they come
> >> > into play here.
> >> >
> >>
> >> I don't mean SVAM should have switched these addresses to virtual ones
> >> but doesn't all of EFI_BOOT_SERVICES_{CODE|DATA} have address[63] = 0?
> >>
> >
> >Whether a mapping has bit 63 set or cleared depends on the location of
> >the mapping in the virtual address space, not on the location of the
> >physical backing of that mapping.
> >
> >efi_check_for_embedded_firmwares() maps EFI_BOOT_SERVICES_DATA regions
> >in the kernel region, so bit 63 will be set.
> >
> >> LASS wouldn't care whether there is an actual mapping behind the
> >> address. It only relies on the MSB for enforcement. So, any code that
> >> relied on accessing boot services memory before efi_free_boot_services()
> >> could get affected by LASS.
> >>
> >
> >This only applies to code that accesses boot services memory via a
> >mapping in the lower range.
> >
> >> >>   3) Some runtime services fail to switch to virtual mode properly and
> >> >>   continue referencing physical addresses [3]. The kernel maintains a
> >> >>   1:1 mapping of all runtime services code and data regions to avoid
> >> >>   breaking such firmware.
> >> >>
> >> >
> >> > In [3], I mainly elaborated on why it is still necessary to call
> >> > SetVirtualAddressMap(), and why it needs to be called with a mapping
> >> > in the upper address range.
> >> >
> >> > For this particular call, there is no choice but to disarm LASS, given
> >> > that the lower mapping is still active at this point.
> >> >
> >> > However, that does not imply that we have to assume that systems that
> >> > support LASS (which are fairly recent AIUI) are buggy in the same way,
> >> > i.e., that they access addresses in the 1:1 region after
> >> > SetVirtualAddressMap() completes.
> >>
> >> I assumed that it must be widespread because the kernel maintains the
> >> 1:1 mapping unconditionally without any Family-model checks. The code
> >> isn't explicitly warning about such implementations, either.
> >>
> >
> >Exactly, and this is an oversight that occured 10+ years ago. No
> >reason to keep carrying that forward forever.
> >
> >> >
> >> > In fact, we might attempt to use the availability of LASS as a
> >> > preliminary cutoff point for disabling this hack entirely, and only
> >> > backpedal if we get actual reports where this is still a problem.
> >>
> >> Sure, I am onboard with this approach, but some folks seemed skeptical
> >> about it during the base LASS series review. My only concern is breaking
> >> user systems when they update to a LASS-enabled kernel.
> >>
> >> x86 maintainers, any preference?
> >>
> >> Would it be useful to put this (patch 2) behind an "efi=disable_lass"
> >> command line option? That way, if someone runs into it, there is at
> >> least a fallback option they can rely on. By default, we would still
> >> expect newer firmware to not need this hack.
> >>
> >
> >efi=noruntime is already available, which may be sufficient to work
> >around this in individual cases, to regain access to a non-booting
> >system.
>
> You are missing something *really* important:
>
> What do you expect to gain?
>
> There is basically no downside to the current workaround, which is why it is unconditional.
>

The downside is that it requires LASS to be disabled - that is the
point of this discussion.

I think proactively carrying over this workaround to LASS systems
without any idea whether or not it is even needed is not the right way
to go about this.

> All it takes is the BIOS developer missing to register *one* pointer and this problem is back.
>
> The *real* bug is the BIOSes that not only require the use of SetVirtualMap() in the first place, but require a non-1:1 mapping in the upper half. For Linux it would be far better to *only* have the restricted 1:1 mapping in the lower address space, as it wouldn't molest the kernel address layout which affects, especially, kexec.
>

Agreed. On arm64, we stopped calling SetVirtualAddressMap() years ago,
and just use the 1:1 mapping at runtime.

This is not feasible on x86, of course, due to the many buggy
implementations. But it would also mean no LASS for EFI calls, right?

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

[H. Peter Anvin]

On December 4, 2025 11:40:03 AM PST, Ard Biesheuvel <ardb@kernel.org> wrote:
>On Thu, 4 Dec 2025 at 20:16, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> On December 4, 2025 11:03:52 AM PST, Ard Biesheuvel <ardb@kernel.org> wrote:
>> >On Thu, 4 Dec 2025 at 18:34, Sohil Mehta <sohil.mehta@intel.com> wrote:
>> >>
>> >> On 12/4/2025 4:47 AM, Ard Biesheuvel wrote:
>> >> > Hello Sohil,
>> >> >
>> >>
>> >> Hello Ard - Thank you for looking at the patches.
>> >>
>> >>
>> >> >>
>> >> >>   2) Boot services code and data are referenced long after
>> >> >>   ExitBootServices(). For example, efi_check_for_embedded_firmwares()
>> >> >>   accesses boot services memory even after SetVirtualAddressMap().
>> >> >>
>> >> >
>> >> > These accesses use the kernel direct map, so I don't think they come
>> >> > into play here.
>> >> >
>> >>
>> >> I don't mean SVAM should have switched these addresses to virtual ones
>> >> but doesn't all of EFI_BOOT_SERVICES_{CODE|DATA} have address[63] = 0?
>> >>
>> >
>> >Whether a mapping has bit 63 set or cleared depends on the location of
>> >the mapping in the virtual address space, not on the location of the
>> >physical backing of that mapping.
>> >
>> >efi_check_for_embedded_firmwares() maps EFI_BOOT_SERVICES_DATA regions
>> >in the kernel region, so bit 63 will be set.
>> >
>> >> LASS wouldn't care whether there is an actual mapping behind the
>> >> address. It only relies on the MSB for enforcement. So, any code that
>> >> relied on accessing boot services memory before efi_free_boot_services()
>> >> could get affected by LASS.
>> >>
>> >
>> >This only applies to code that accesses boot services memory via a
>> >mapping in the lower range.
>> >
>> >> >>   3) Some runtime services fail to switch to virtual mode properly and
>> >> >>   continue referencing physical addresses [3]. The kernel maintains a
>> >> >>   1:1 mapping of all runtime services code and data regions to avoid
>> >> >>   breaking such firmware.
>> >> >>
>> >> >
>> >> > In [3], I mainly elaborated on why it is still necessary to call
>> >> > SetVirtualAddressMap(), and why it needs to be called with a mapping
>> >> > in the upper address range.
>> >> >
>> >> > For this particular call, there is no choice but to disarm LASS, given
>> >> > that the lower mapping is still active at this point.
>> >> >
>> >> > However, that does not imply that we have to assume that systems that
>> >> > support LASS (which are fairly recent AIUI) are buggy in the same way,
>> >> > i.e., that they access addresses in the 1:1 region after
>> >> > SetVirtualAddressMap() completes.
>> >>
>> >> I assumed that it must be widespread because the kernel maintains the
>> >> 1:1 mapping unconditionally without any Family-model checks. The code
>> >> isn't explicitly warning about such implementations, either.
>> >>
>> >
>> >Exactly, and this is an oversight that occured 10+ years ago. No
>> >reason to keep carrying that forward forever.
>> >
>> >> >
>> >> > In fact, we might attempt to use the availability of LASS as a
>> >> > preliminary cutoff point for disabling this hack entirely, and only
>> >> > backpedal if we get actual reports where this is still a problem.
>> >>
>> >> Sure, I am onboard with this approach, but some folks seemed skeptical
>> >> about it during the base LASS series review. My only concern is breaking
>> >> user systems when they update to a LASS-enabled kernel.
>> >>
>> >> x86 maintainers, any preference?
>> >>
>> >> Would it be useful to put this (patch 2) behind an "efi=disable_lass"
>> >> command line option? That way, if someone runs into it, there is at
>> >> least a fallback option they can rely on. By default, we would still
>> >> expect newer firmware to not need this hack.
>> >>
>> >
>> >efi=noruntime is already available, which may be sufficient to work
>> >around this in individual cases, to regain access to a non-booting
>> >system.
>>
>> You are missing something *really* important:
>>
>> What do you expect to gain?
>>
>> There is basically no downside to the current workaround, which is why it is unconditional.
>>
>
>The downside is that it requires LASS to be disabled - that is the
>point of this discussion.
>
>I think proactively carrying over this workaround to LASS systems
>without any idea whether or not it is even needed is not the right way
>to go about this.
>
>> All it takes is the BIOS developer missing to register *one* pointer and this problem is back.
>>
>> The *real* bug is the BIOSes that not only require the use of SetVirtualMap() in the first place, but require a non-1:1 mapping in the upper half. For Linux it would be far better to *only* have the restricted 1:1 mapping in the lower address space, as it wouldn't molest the kernel address layout which affects, especially, kexec.
>>
>
>Agreed. On arm64, we stopped calling SetVirtualAddressMap() years ago,
>and just use the 1:1 mapping at runtime.
>
>This is not feasible on x86, of course, due to the many buggy
>implementations. But it would also mean no LASS for EFI calls, right?
>

But your underlying assumption is that disabling LASS around EFI calls is a problem. It isn't, because the efi_mm has explicitly unmapped any memory EFI isn't allowed to touch. In other words, we are already doing the equivalent of LASS "manually."

I don't see any value at all in keeping LASS on *when efi_mm is active.* By which I mean that LASS needs to be on until after efi_mm is active, and be active before switching to another mm.

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

[Ard Biesheuvel]

On Thu, 4 Dec 2025 at 20:51, H. Peter Anvin <hpa@zytor.com> wrote:
>
> On December 4, 2025 11:40:03 AM PST, Ard Biesheuvel <ardb@kernel.org> wrote:
> >On Thu, 4 Dec 2025 at 20:16, H. Peter Anvin <hpa@zytor.com> wrote:
> >>
> >> On December 4, 2025 11:03:52 AM PST, Ard Biesheuvel <ardb@kernel.org> wrote:
> >> >On Thu, 4 Dec 2025 at 18:34, Sohil Mehta <sohil.mehta@intel.com> wrote:
> >> >>
> >> >> On 12/4/2025 4:47 AM, Ard Biesheuvel wrote:
> >> >> > Hello Sohil,
> >> >> >
> >> >>
> >> >> Hello Ard - Thank you for looking at the patches.
> >> >>
> >> >>
> >> >> >>
> >> >> >>   2) Boot services code and data are referenced long after
> >> >> >>   ExitBootServices(). For example, efi_check_for_embedded_firmwares()
> >> >> >>   accesses boot services memory even after SetVirtualAddressMap().
> >> >> >>
> >> >> >
> >> >> > These accesses use the kernel direct map, so I don't think they come
> >> >> > into play here.
> >> >> >
> >> >>
> >> >> I don't mean SVAM should have switched these addresses to virtual ones
> >> >> but doesn't all of EFI_BOOT_SERVICES_{CODE|DATA} have address[63] = 0?
> >> >>
> >> >
> >> >Whether a mapping has bit 63 set or cleared depends on the location of
> >> >the mapping in the virtual address space, not on the location of the
> >> >physical backing of that mapping.
> >> >
> >> >efi_check_for_embedded_firmwares() maps EFI_BOOT_SERVICES_DATA regions
> >> >in the kernel region, so bit 63 will be set.
> >> >
> >> >> LASS wouldn't care whether there is an actual mapping behind the
> >> >> address. It only relies on the MSB for enforcement. So, any code that
> >> >> relied on accessing boot services memory before efi_free_boot_services()
> >> >> could get affected by LASS.
> >> >>
> >> >
> >> >This only applies to code that accesses boot services memory via a
> >> >mapping in the lower range.
> >> >
> >> >> >>   3) Some runtime services fail to switch to virtual mode properly and
> >> >> >>   continue referencing physical addresses [3]. The kernel maintains a
> >> >> >>   1:1 mapping of all runtime services code and data regions to avoid
> >> >> >>   breaking such firmware.
> >> >> >>
> >> >> >
> >> >> > In [3], I mainly elaborated on why it is still necessary to call
> >> >> > SetVirtualAddressMap(), and why it needs to be called with a mapping
> >> >> > in the upper address range.
> >> >> >
> >> >> > For this particular call, there is no choice but to disarm LASS, given
> >> >> > that the lower mapping is still active at this point.
> >> >> >
> >> >> > However, that does not imply that we have to assume that systems that
> >> >> > support LASS (which are fairly recent AIUI) are buggy in the same way,
> >> >> > i.e., that they access addresses in the 1:1 region after
> >> >> > SetVirtualAddressMap() completes.
> >> >>
> >> >> I assumed that it must be widespread because the kernel maintains the
> >> >> 1:1 mapping unconditionally without any Family-model checks. The code
> >> >> isn't explicitly warning about such implementations, either.
> >> >>
> >> >
> >> >Exactly, and this is an oversight that occured 10+ years ago. No
> >> >reason to keep carrying that forward forever.
> >> >
> >> >> >
> >> >> > In fact, we might attempt to use the availability of LASS as a
> >> >> > preliminary cutoff point for disabling this hack entirely, and only
> >> >> > backpedal if we get actual reports where this is still a problem.
> >> >>
> >> >> Sure, I am onboard with this approach, but some folks seemed skeptical
> >> >> about it during the base LASS series review. My only concern is breaking
> >> >> user systems when they update to a LASS-enabled kernel.
> >> >>
> >> >> x86 maintainers, any preference?
> >> >>
> >> >> Would it be useful to put this (patch 2) behind an "efi=disable_lass"
> >> >> command line option? That way, if someone runs into it, there is at
> >> >> least a fallback option they can rely on. By default, we would still
> >> >> expect newer firmware to not need this hack.
> >> >>
> >> >
> >> >efi=noruntime is already available, which may be sufficient to work
> >> >around this in individual cases, to regain access to a non-booting
> >> >system.
> >>
> >> You are missing something *really* important:
> >>
> >> What do you expect to gain?
> >>
> >> There is basically no downside to the current workaround, which is why it is unconditional.
> >>
> >
> >The downside is that it requires LASS to be disabled - that is the
> >point of this discussion.
> >
> >I think proactively carrying over this workaround to LASS systems
> >without any idea whether or not it is even needed is not the right way
> >to go about this.
> >
> >> All it takes is the BIOS developer missing to register *one* pointer and this problem is back.
> >>
> >> The *real* bug is the BIOSes that not only require the use of SetVirtualMap() in the first place, but require a non-1:1 mapping in the upper half. For Linux it would be far better to *only* have the restricted 1:1 mapping in the lower address space, as it wouldn't molest the kernel address layout which affects, especially, kexec.
> >>
> >
> >Agreed. On arm64, we stopped calling SetVirtualAddressMap() years ago,
> >and just use the 1:1 mapping at runtime.
> >
> >This is not feasible on x86, of course, due to the many buggy
> >implementations. But it would also mean no LASS for EFI calls, right?
> >
>
> But your underlying assumption is that disabling LASS around EFI calls is a problem. It isn't, because the efi_mm has explicitly unmapped any memory EFI isn't allowed to touch. In other words, we are already doing the equivalent of LASS "manually."
>

I must have misunderstood then - there was some pushback on this IIRC
but if en/disabling LASS is fine then sure.

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

[Sohil Mehta]

On 12/4/2025 11:03 AM, Ard Biesheuvel wrote:
> 
> efi_check_for_embedded_firmwares() maps EFI_BOOT_SERVICES_DATA regions
> in the kernel region, so bit 63 will be set.

Ah, I missed that efi_check_for_embedded_firmwares() remaps the regions.

> 
>> LASS wouldn't care whether there is an actual mapping behind the
>> address. It only relies on the MSB for enforcement. So, any code that
>> relied on accessing boot services memory before efi_free_boot_services()
>> could get affected by LASS.
>>
> 
> This only applies to code that accesses boot services memory via a
> mapping in the lower range.
> 

Yes, I was referring to usages which use the lower mapping. Though,
efi_check_for_embedded_firmwares() doesn't do that, enabling LASS after
freeing boot services memory is still the right thing to do. In theory,
someone could use the 1:1 mapping.

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

[Sohil Mehta]

On 12/4/2025 11:58 AM, Ard Biesheuvel wrote:
> On Thu, 4 Dec 2025 at 20:51, H. Peter Anvin <hpa@zytor.com> wrote:
>> 
>> But your underlying assumption is that disabling LASS around EFI
>> calls is a problem. It isn't, because the efi_mm has explicitly
>> unmapped any memory EFI isn't allowed to touch. In other words, we
>> are already doing the equivalent of LASS "manually."
>> 
> 
> I must have misunderstood then - there was some pushback on this
> IIRC but if en/disabling LASS is fine then sure.
Thanks for the feedback! I'll leave the patches as-is then and wait for
additional comments.