Message-ID: <bbb68600-eea9-45d8-90d1-bc4619186a4d@intel.com>
Date: Fri, 7 Nov 2025 12:08:21 -0800
From: Sohil Mehta <sohil.mehta@...el.com>
To: "H. Peter Anvin" <hpa@...or.com>, Dave Hansen <dave.hansen@...el.com>,
	<x86@...nel.org>, Dave Hansen <dave.hansen@...ux.intel.com>, Thomas Gleixner
	<tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
	<bp@...en8.de>
CC: Jonathan Corbet <corbet@....net>, Andy Lutomirski <luto@...nel.org>, "Josh
 Poimboeuf" <jpoimboe@...nel.org>, Peter Zijlstra <peterz@...radead.org>, "Ard
 Biesheuvel" <ardb@...nel.org>, "Kirill A . Shutemov" <kas@...nel.org>, Xin Li
	<xin@...or.com>, David Woodhouse <dwmw@...zon.co.uk>, Sean Christopherson
	<seanjc@...gle.com>, Rick Edgecombe <rick.p.edgecombe@...el.com>, "Vegard
 Nossum" <vegard.nossum@...cle.com>, Andrew Cooper
	<andrew.cooper3@...rix.com>, Randy Dunlap <rdunlap@...radead.org>, Geert
 Uytterhoeven <geert@...ux-m68k.org>, Kees Cook <kees@...nel.org>, Tony Luck
	<tony.luck@...el.com>, Alexander Shishkin
	<alexander.shishkin@...ux.intel.com>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-efi@...r.kernel.org>
Subject: Re: [PATCH v11 9/9] x86/cpu: Enable LASS by default during CPU
 initialization

On 11/7/2025 12:01 AM, H. Peter Anvin wrote:
>> 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.
> 

Yes, the actual change is quite simple. But along with minor refactoring
and updates to code comments and documentation, it ends up being a set
of 3 to 4 small patches.

> 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*.
> 

At a minimum, We need to defer the initial LASS enabling until we are
truly done with the boot services memory, i.e. efi_enter_virtual_mode()
has completed (including efi_free_boot_services()).

Also, there is preference for deferring LASS enabling until userspace
comes up. Again, all of that should be simple enough but ends up adding
to the patch count (touching 20 now). It was getting difficult to get
the reviews/acks from experts in all the impacted areas.

Dave's suggestion of splitting the series makes it easier to merge the
base set and get focussed reviews on the missing features. My plan is to
promptly follow up with the EFI and Vsyscall support to make LASS
enabled by default.

> 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

Yes, there is absolutely no need to support the full vsyscall emulation.

> 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.
> 

This seems to be the takeaway of PeterZ's interaction with Ard. Though,
I agree, warning about misbehaving firmware should probably be done
separately and independent of LASS.

I'll send out another revision of this series without EFI next week, and
follow up with support for EFI and vsyscall soon after.

Powered by blists - more mailing lists