linux-kernel - Re: [PATCH v11 4/9] x86/alternatives: Disable LASS when patching kernel code

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: <E9396874-5D2D-413D-A5D1-A28E4D429C51@zytor.com>
Date: Wed, 12 Nov 2025 07:23:02 -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: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.