Re: [PATCH v11 5/9] x86/efi: Disable LASS while mapping the EFI runtime services

[Dave Hansen <dave.hansen@intel.com>]

On 10/31/25 11:03, Sohil Mehta wrote:
>> Deferring is a good idea. I was just asking for the same thing for the
>> CR pinning enforcement. The earlier we try to do these things, the more
>> we just trip over ourselves.
> I had suggested deferring as well to Kirill when I was reviewing the
> series. He preferred to enable LASS with other similar features such as
> SMAP, SMEP.
> 
> One other thing to consider:
> 
> Doing it in identify_cpu() makes it easy for all the APs to program
> their CR4.LASS bit. If we were to defer it, we would need some
> additional work to setup all the APs.

That's true. We'd need an smp_call_function() of some kind. *But*, once
that is in place, it's hopefully just a matter of moving that one line
of code per feature from identify_cpu() over to the new function.

> Do we already do this for something else? That would make it easier to
> tag along.

We don't do it for anything else that I can think of.

But there's a pretty broad set of things that are for "security" that
aren't necessary while you're just running trusted ring0 code:

 * SMAP/SMEP
 * CR pinning itself
 * MSR_IA32_SPEC_CTRL
 * MSR_IA32_TSX_CTRL

They just haven't mattered until now because they don't have any
practical effect until you actually have code running on _PAGE_USER
mappings trying to attack the kernel.