arch/x86/kernel/cpu/common.c | 24 +++++++++++++++++------- arch/x86/platform/efi/efi_64.c | 31 +++++++++++++++++++++++++++++++ 2 files changed, 48 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. 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
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.
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.
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.
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.
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.
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?
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.
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.
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.
© 2016 - 2025 Red Hat, Inc.