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

[PATCH v2 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.

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

[PATCH v2 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(). The boot services memory is truly freed during
efi_free_boot_services() after SVAM has completed.

To prevent EFI from tripping LASS, 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 that would make the
implementation very fragile. Something else might come in the future
that would need 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>
---
v2:
 - Add code comments for clarity.
---
 arch/x86/kernel/cpu/common.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index e7ab22fce3b5..cefd0722e6cc 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -422,12 +422,33 @@ 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;
 }
 
+/*
+ * Finalize features that need to be enabled just before entering
+ * userspace. Note that this only runs on a single CPU. Use appropriate
+ * callbacks if all the CPUs need to reflect the same change.
+ */
+static int cpu_finalize_pre_userspace(void)
+{
+	if (!cpu_feature_enabled(X86_FEATURE_LASS))
+		return 0;
+
+	/* Runs on all online CPUs and future CPUs that come online. */
+	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

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

[Sohil Mehta]

On 1/20/2026 3:47 PM, Sohil Mehta wrote:

> +/*
> + * Finalize features that need to be enabled just before entering
> + * userspace. Note that this only runs on a single CPU. Use appropriate
> + * callbacks if all the CPUs need to reflect the same change.
> + */
> +static int cpu_finalize_pre_userspace(void)
> +{
> +	if (!cpu_feature_enabled(X86_FEATURE_LASS))
> +		return 0;
> +
> +	/* Runs on all online CPUs and future CPUs that come online. */
> +	cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/lass:enable", enable_lass, NULL);
> +
> +	return 0;
> +}
> +late_initcall(cpu_finalize_pre_userspace);
> +

@Dave, Nikunj,

The current patch
	https://lore.kernel.org/lkml/1bc0b798-9cef-4dfd-af06-7674b699af1b@intel.com/

..to defer CR pinning enforcement until CPU online makes sense for the
FRED fix. Eventually, I am thinking we can defer CR pinning even further
until userspace comes up.

setup_cr_pinning(), which enables the static key, can be moved to a
late_initcall() such as above. The cpu_online() check to enforce CR
pinning would still be needed to make it play nice with CPU hotplug.

Do you see an issue with that approach?

>  /* 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;

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

[Dave Hansen]

On 2/19/26 13:02, Sohil Mehta wrote:
> The current patch
> 	https://lore.kernel.org/lkml/1bc0b798-9cef-4dfd-af06-7674b699af1b@intel.com/
> 
> ..to defer CR pinning enforcement until CPU online makes sense for the
> FRED fix. Eventually, I am thinking we can defer CR pinning even further
> until userspace comes up.
> 
> setup_cr_pinning(), which enables the static key, can be moved to a
> late_initcall() such as above. The cpu_online() check to enforce CR
> pinning would still be needed to make it play nice with CPU hotplug.
> 
> Do you see an issue with that approach?

Seems fine to me.

[PATCH v2 2/3] x86/efi: Disable LASS while executing runtime services

[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. Runtime services are called in the
context of efi_mm, which has explicitly unmapped any memory EFI isn't
allowed to touch (including userspace). So, do this right after
switching to efi_mm to avoid any 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>
---
v2:
 - Improve commit message and code comments.
---
 arch/x86/platform/efi/efi_64.c | 35 ++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index b4409df2105a..5861008eab22 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,50 @@ 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 only after switching to EFI-mm, as userspace is not
+ * mapped in it. Similar to EFI-mm, these rely on preemption being
+ * disabled and the calls being serialized.
+ */
+
+static void efi_disable_lass(void)
+{
+	if (!cpu_feature_enabled(X86_FEATURE_LASS))
+		return;
+
+	lockdep_assert_preemption_disabled();
+
+	/* 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;
+
+	lockdep_assert_preemption_disabled();
+
+	/* 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 v2 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.

Remove the LASS restriction on EFI config, as the two can now coexist.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v2:
 - No change
---
 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 cefd0722e6cc..5833849f0b52 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 v2 0/3] x86: Extend LASS support to EFI configurations

[Maciej Wieczor-Retman]

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
>

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

[Luck, Tony]

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

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

[Sohil Mehta]

Hello x86 Maintainers, Ard,

On 1/20/2026 3:47 PM, Sohil Mehta wrote:
> 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].
> 

The patches now have tested-by tags from Maciej and Tony. Also, the
patches apply cleanly on v7.0-rc1. I am hoping to get some review
feedback on the patches before resending another version.

Ard, are you okay with patch 2 that disables LASS during EFI runtime calls?

x86 Maintainers, patch 1 introduces a common mechanism to defer
initializing features until userspace is about to come up. In the
future, enabling of features (such as SMAP, SMEP, UMIP) and CR pinning,
SPEC_CTRL MSR can be moved here.

Also, there is a possibility that the freeing of EFI boot services
memory might happen later based on the recent discussion at:
https://lore.kernel.org/lkml/20260223075219.2348035-1-rppt@kernel.org/

Overall, the approach in patch 1 seems useful. The implementation is
based on a combination of late_initcall() and CPU hotplug callbacks.
Thoughts?

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

[Ard Biesheuvel]

On Tue, 24 Feb 2026, at 19:45, Sohil Mehta wrote:
> Hello x86 Maintainers, Ard,
>
> On 1/20/2026 3:47 PM, Sohil Mehta wrote:
>> 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].
>> 
>
> The patches now have tested-by tags from Maciej and Tony. Also, the
> patches apply cleanly on v7.0-rc1. I am hoping to get some review
> feedback on the patches before resending another version.
>
> Ard, are you okay with patch 2 that disables LASS during EFI runtime calls?
>

Yeah I think that's fine.

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

[Dave Hansen]

On 2/24/26 10:45, Sohil Mehta wrote:
> Overall, the approach in patch 1 seems useful. The implementation is
> based on a combination of late_initcall() and CPU hotplug callbacks.
> Thoughts?

It looks great, actually. It's really nice how the CPU hotplug
infrastructure takes care of all the hard work.

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

[Maciej Wieczor-Retman]

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>

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
>

-- 
Kind regards
Maciej Wieczór-Retman