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@xxxxxxxxx> wrote:
>
> On December 4, 2025 11:03:52 AM PST, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> >On Thu, 4 Dec 2025 at 18:34, Sohil Mehta <sohil.mehta@xxxxxxxxx> 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?