Re: [PATCH 0/3] x86: Extend LASS support to EFI configurations

[Sohil Mehta <sohil.mehta@intel.com>]

On 12/4/2025 4:47 AM, Ard Biesheuvel wrote:
> Hello Sohil,
> 

Hello Ard - Thank you for looking at the patches.


>>
>>   2) Boot services code and data are referenced long after
>>   ExitBootServices(). For example, efi_check_for_embedded_firmwares()
>>   accesses boot services memory even after SetVirtualAddressMap().
>>
> 
> These accesses use the kernel direct map, so I don't think they come
> into play here.
> 

I don't mean SVAM should have switched these addresses to virtual ones
but doesn't all of EFI_BOOT_SERVICES_{CODE|DATA} have address[63] = 0?

LASS wouldn't care whether there is an actual mapping behind the
address. It only relies on the MSB for enforcement. So, any code that
relied on accessing boot services memory before efi_free_boot_services()
could get affected by LASS.

Or, did I misunderstand your comment? I am trying to clarify because I
have similar wording in the commit messages, and it would be preferable
to keep that accurate.

>>   3) Some runtime services fail to switch to virtual mode properly and
>>   continue referencing physical addresses [3]. The kernel maintains a
>>   1:1 mapping of all runtime services code and data regions to avoid
>>   breaking such firmware.
>>
> 
> In [3], I mainly elaborated on why it is still necessary to call
> SetVirtualAddressMap(), and why it needs to be called with a mapping
> in the upper address range.
> 
> For this particular call, there is no choice but to disarm LASS, given
> that the lower mapping is still active at this point.
> 
> However, that does not imply that we have to assume that systems that
> support LASS (which are fairly recent AIUI) are buggy in the same way,
> i.e., that they access addresses in the 1:1 region after
> SetVirtualAddressMap() completes.

I assumed that it must be widespread because the kernel maintains the
1:1 mapping unconditionally without any Family-model checks. The code
isn't explicitly warning about such implementations, either.

> 
> In fact, we might attempt to use the availability of LASS as a
> preliminary cutoff point for disabling this hack entirely, and only
> backpedal if we get actual reports where this is still a problem. 

Sure, I am onboard with this approach, but some folks seemed skeptical
about it during the base LASS series review. My only concern is breaking
user systems when they update to a LASS-enabled kernel.

x86 maintainers, any preference?

Would it be useful to put this (patch 2) behind an "efi=disable_lass"
command line option? That way, if someone runs into it, there is at
least a fallback option they can rely on. By default, we would still
expect newer firmware to not need this hack.