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

H. Peter Anvin
2025-11-12T15:23:52Z

On November 12, 2025 7:18:33 AM PST, Ard Biesheuvel <ardb@kernel.org> wrote:
>On Wed, 12 Nov 2025 at 15:58, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>> On November 12, 2025 6:51:45 AM PST, Dave Hansen <dave.hansen@intel.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.