Message-ID: <CAMj1kXEQFhdZ4kcObsxNoj2cK+TGS=xBU83ARVrifxjw8yPcJQ@mail.gmail.com>
Date: Thu, 4 Dec 2025 20:58:47 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Sohil Mehta <sohil.mehta@...el.com>, x86@...nel.org, 
	Dave Hansen <dave.hansen@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Andy Lutomirski <luto@...nel.org>, 
	Peter Zijlstra <peterz@...radead.org>, Kiryl Shutsemau <kas@...nel.org>, 
	Rick Edgecombe <rick.p.edgecombe@...el.com>, Andrew Cooper <andrew.cooper3@...rix.com>, 
	Tony Luck <tony.luck@...el.com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, linux-kernel@...r.kernel.org, 
	linux-efi@...r.kernel.org
Subject: Re: [PATCH 0/3] x86: Extend LASS support to EFI configurations

On Thu, 4 Dec 2025 at 20:51, H. Peter Anvin <hpa@...or.com> wrote:
>
> On December 4, 2025 11:40:03 AM PST, Ard Biesheuvel <ardb@...nel.org> wrote:
> >On Thu, 4 Dec 2025 at 20:16, H. Peter Anvin <hpa@...or.com> wrote:
> >>
> >> On December 4, 2025 11:03:52 AM PST, Ard Biesheuvel <ardb@...nel.org> wrote:
> >> >On Thu, 4 Dec 2025 at 18:34, Sohil Mehta <sohil.mehta@...el.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.

Powered by blists - more mailing lists