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: <CAMj1kXHFQYN8QF5Sd4ObsCziM-0gitGS5D1S1qCscKpQaZVDLA@mail.gmail.com>
Date: Fri, 7 Nov 2025 11:17:26 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Dave Hansen <dave.hansen@...el.com>, 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>, 
	"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, 7 Nov 2025 at 11:10, Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Fri, Nov 07, 2025 at 10:22:30AM +0100, Ard Biesheuvel wrote:
>
> > There is also PRM, which is much worse, as it permits devices in the
> > ACPI namespace to call firmware routines that are mapped privileged in
> > the OS address space in the same way. I objected to this at the time,
> > and asked for a facility where we could at least mark such code as
> > unprivileged (and run it as such) but this was ignored, as Intel and
> > MS had already sealed the deal and put this into production. This is
> > much worse than typical EFI routines, as the PRM code is ODM/OEM code
> > rather than something that comes from the upstream EFI implementation.
> > It is basically a dumping ground for code that used to run in SMM
> > because it was too ugly to run anywhere else. </rant>
>
> 'https://uefi.org/sites/default/files/resources/Platform Runtime Mechanism - with legal notice.pdf'
>
> Has on page 16, section 3.1:
>
>   8. PRM handlers must not contain any privileged instructions.
>
> So we should be able to actually run this crap in ring3, right?

How interesting! This wasn't in the draft that I reviewed at the time,
so someone did listen.

So it does seem feasible to drop privileges and reacquire them in
principle, as long as we ensure that all the memory touched by the PRM
services (stack, code, data, MMIO regions) is mapped appropriately in
the EFI memory map.