Message-ID: <2D5B8457-7A69-4DE6-884F-61E20D1A6976@zytor.com>
Date: Wed, 12 Nov 2025 07:47:28 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Ard Biesheuvel <ardb@...nel.org>
CC: Dave Hansen <dave.hansen@...el.com>, Sohil Mehta <sohil.mehta@...el.com>,
        x86@...nel.org, Borislav Petkov <bp@...en8.de>,
        Jonathan Corbet <corbet@....net>, Andy Lutomirski <luto@...nel.org>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Kirill A . Shutemov" <kas@...nel.org>, Xin Li <xin@...or.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Sean Christopherson <seanjc@...gle.com>,
        Rick Edgecombe <rick.p.edgecombe@...el.com>,
        Vegard Nossum <vegard.nossum@...cle.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>, Kees Cook <kees@...nel.org>,
        Tony Luck <tony.luck@...el.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-efi@...r.kernel.org, Dave Hansen <dave.hansen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH v11 4/9] x86/alternatives: Disable LASS when patching kernel code

On November 12, 2025 7:28:12 AM PST, Ard Biesheuvel <ardb@...nel.org> wrote:
>On Wed, 12 Nov 2025 at 16:23, H. Peter Anvin <hpa@...or.com> wrote:
>>
>> On November 12, 2025 7:18:33 AM PST, Ard Biesheuvel <ardb@...nel.org> wrote:
>> >On Wed, 12 Nov 2025 at 15:58, H. Peter Anvin <hpa@...or.com> wrote:
>> >>
>> >> On November 12, 2025 6:51:45 AM PST, Dave Hansen <dave.hansen@...el.com> wrote:
>> >> >On 11/12/25 05:56, Ard Biesheuvel wrote:
>> >> >...
>> >> >>> it looks like we would now need to toggle
>> >> >>> CR4.LASS every time we switch to efi_mm. The lass_enable()/_disable()
>> >> >>> naming would be more suitable for those wrappers.
>> >> >>>
>> >> >> Note that Linux/x86 uses SetVirtualAddressMap() to remap all EFI
>> >> >> runtime regions into the upper [kernel] half of the address space.
>> >> >>
>> >> >> SetVirtualAddressMap() itself is a terrible idea, but given that we
>> >> >> are already stuck with it, we should be able to rely on ordinary EFI
>> >> >> runtime calls to only execute from the upper address range. The only
>> >> >> exception is the call to SetVirtualAddressMap() itself, which occurs
>> >> >> only once during early boot.
>> >> >
>> >> >Gah, I had it in my head that we needed to use the lower mapping at
>> >> >runtime. The efi_mm gets used for that SetVirtualAddressMap() and the
>> >> >efi_mm continues to get used at runtime. So I think I just assumed that
>> >> >the lower mappings needed to get used too.
>> >> >
>> >> >Thanks for the education!
>> >> >
>> >> >Let's say we simply delayed CR4.LASS=1 until later in boot. Could we
>> >> >completely ignore LASS during EFI calls, since the calls only use the
>> >> >upper address range?
>> >> >
>> >> >Also, in practice, are there buggy EFI implementations that use the
>> >> >lower address range even though they're not supposed to? *If* we just
>> >> >keep LASS on for these calls is there a chance it will cause a
>> >> >regression in some buggy EFI implementations?
>> >>
>> >> Yes, they are. And there are buggy ones which die if set up with virtual addresses in the low half.
>> >
>> >To elaborate on that, there are systems where
>> >
>> >a) not calling SetVirtualAddressMap() crashes the firmware, because,
>> >in spite of being clearly documented as optional, not calling it
>> >results in some event hook not being called, causing the firmware to
>> >misbehave
>> >
>> >b) calling SetVirtualAddressMap() with an 1:1 mapping crashes the
>> >firmware (and so this is not a possible workaround for a))
>> >
>> >c) calling SetVirtualAddressMap() crashes the firmware when not both
>> >the old 1:1 and the new kernel mapping are already live (which
>> >violates the UEFI spec)
>> >
>> >d) calling SetVirtualAddressMap() does not result in all 1:1
>> >references being converted to the new mapping.
>> >
>> >
>> >To address d), the x86_64 implementation of efi_map_region() indeed
>> >maps an 1:1 alias of each remapped runtime regions, so that stray
>> >accesses don't fault. But the code addresses are all remapped, and so
>> >the firmware routines are always invoked via their remapped aliases in
>> >the kernel VA space. Not calling SetVirtualAddressMap() at all, or
>> >calling it with a 1:1 mapping is not feasible, essentially because
>> >Windows doesn't do that, and that is the only thing that is tested on
>> >all x86 PCs by the respective OEMs.
>> >
>> >Given that remapping the code is dealt with by the firmware's PE/COFF
>> >loader, whereas remapping [dynamically allocated] data requires effort
>> >on the part of the programmer, I'd hazard a guess that 99.9% of those
>> >bugs do not involve attempts to execute via the lower mapping, but
>> >stray references to data objects that were not remapped properly.
>> >
>> >So we might consider
>> >a) remapping those 1:1 aliases NX, so we don't have those patches of
>> >RWX memory around
>> >b) keeping LASS enabled during ordinary EFI runtime calls, as you suggest.
>>
>> Unless someone has a code pointer in their code.
>
>That is a good point, especially because the EFI universe is
>constructed out of GUIDs and so-called protocols, which are just
>structs with function pointers.
>
>However, EFI protocols are only supported at boot time, and the
>runtime execution context is much more restricted. So I'd still expect
>the code pointer case to be much less likely.

Yes, but it only takes one. 

The main thing, though, is that this is being bikeshedded for no good reason: there isn't much to be had from trying to narrow down from what we have now, other than restricting the *upper* mapping further.

And this has nothing to do with LASS.

Powered by blists - more mailing lists