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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <efd6ec82-5576-41f1-a244-2f80d72e93e4@intel.com>
Date: Fri, 31 Oct 2025 11:03:14 -0700
From: Sohil Mehta <sohil.mehta@...el.com>
To: Dave Hansen <dave.hansen@...el.com>, Andy Lutomirski <luto@...nel.org>,
	the arch/x86 maintainers <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>, "H. Peter Anvin" <hpa@...or.com>, "Josh
 Poimboeuf" <jpoimboe@...nel.org>, "Peter Zijlstra (Intel)"
	<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 P
 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 Mailing List <linux-kernel@...r.kernel.org>,
	<linux-efi@...r.kernel.org>
Subject: Re: [PATCH v11 5/9] x86/efi: Disable LASS while mapping the EFI
 runtime services

On 10/31/2025 10:41 AM, Dave Hansen wrote:
> On 10/31/25 10:38, Andy Lutomirski wrote:
>> Am I imagining an issue that doesn’t exist?  Is there some way to be
>> reasonably convinced that you haven’t missed another EFI code path?
>> Would it be ridiculous to defer enabling LASS until we’re almost
>> ready to run user code?

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

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