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: <DDEF6164-D1E6-4003-A251-804738CB59E0@zytor.com>
Date: Wed, 12 Nov 2025 06:57:40 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Dave Hansen <dave.hansen@...el.com>, Ard Biesheuvel <ardb@...nel.org>,
        Sohil Mehta <sohil.mehta@...el.com>
CC: 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 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.