Re: [PATCH v11 9/9] x86/cpu: Enable LASS by default during CPU initialization

H. Peter Anvin
2025-11-07T08:05:05Z

On 2025-10-30 09:27, Dave Hansen wrote:
> On 10/30/25 01:40, H. Peter Anvin wrote:
>> Legacy vsyscalls have been obsolete for how long now?
>
> I asked Sohil to start throwing out all the non-essential bits from this
> series. My thought was that we could get mainline so that LASS itself
> could be enabled, even if it was in a somewhat weird config that a
> distro would probably never do.
>
> After that is merged, we can circle back and decide what to do with the
> remaining bits like CR pinning and vsyscall emulation. I don't think any
> of those bits will change the basic desire to have LASS support in the
> kernel.
>
> Does that sound like a sane approach to everyone?

XONLY vsyscall emulation should be trivial, though (just look for the magic
RIP values, just like the page fault code does now, too.) The FULL emulation
mode is completely irrelevant these days, so I don't think it matters at all.

EFI handling is similarly straightforward: just disable CR4.LASS right before
calling EFI, and enable it on return. As long as we are *already* in the
efi_mm context, it is perfectly safe to disable CR4.LASS, because there *is no
user memory mapped at that point*.

These two things should only be a few lines of code each, and I don't see any
reason to further elaborate them at this time (to handle FULL emulation, or to
take a LASS trap inside EFI to write a shame-the-vendor message; if we wanted
to do that, it would be better to make that independent of LASS and empty out
efi_mm entirely.

Am I missing something?

-hpa