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

[H. Peter Anvin]

On November 12, 2025 6:51:45 AM PST, Dave Hansen <dave.hansen@xxxxxxxxx> 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.