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: <20251107090406.GU3245006@noisy.programming.kicks-ass.net>
Date: Fri, 7 Nov 2025 10:04:06 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Sohil Mehta <sohil.mehta@...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>,
	Jonathan Corbet <corbet@....net>, "H. Peter Anvin" <hpa@...or.com>,
	Josh Poimboeuf <jpoimboe@...nel.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 Fri, Oct 31, 2025 at 11:12:53AM -0700, Dave Hansen wrote:

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

But that's just the thing EFI is *NOT* trusted! We're basically
disabling all security features (not listed above are CET and CFI) to
run this random garbage we have no control over.

How about we just flat out refuse EFI runtime services? What are they
actually needed for? Why are we bending over backwards and subverting
our security for this stuff?