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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXECOBQczcNeqmhfgttz_0545B3m7OgLAk4WE_hOkUbohg@mail.gmail.com>
Date: Thu, 4 Dec 2025 20:03:52 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Sohil Mehta <sohil.mehta@...el.com>
Cc: 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>, 
	"H . Peter Anvin" <hpa@...or.com>, 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 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.