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

["H. Peter Anvin" <hpa@zytor.com>]

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.