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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <B0E164E9-9037-4DD3-BFF6-E628B23349FF@zytor.com>
Date: Thu, 04 Dec 2025 11:15:29 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Ard Biesheuvel <ardb@...nel.org>, 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>, 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 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.

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.