linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Sohil Mehta <sohil.mehta@intel.com>,
	 Andy Lutomirski <luto@kernel.org>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	 Dave Hansen <dave.hansen@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	 Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Jonathan Corbet <corbet@lwn.net>,
	 "H. Peter Anvin" <hpa@zytor.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	 "Kirill A . Shutemov" <kas@kernel.org>, Xin Li <xin@zytor.com>,
	David Woodhouse <dwmw@amazon.co.uk>,
	 Sean Christopherson <seanjc@google.com>,
	Rick P Edgecombe <rick.p.edgecombe@intel.com>,
	 Vegard Nossum <vegard.nossum@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	 Randy Dunlap <rdunlap@infradead.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	 Kees Cook <kees@kernel.org>, Tony Luck <tony.luck@intel.com>,
	 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	linux-doc@vger.kernel.org,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-efi@vger.kernel.org
Subject: Re: [PATCH v11 5/9] x86/efi: Disable LASS while mapping the EFI runtime services
Date: Fri, 7 Nov 2025 11:17:26 +0100	[thread overview]
Message-ID: <CAMj1kXHFQYN8QF5Sd4ObsCziM-0gitGS5D1S1qCscKpQaZVDLA@mail.gmail.com> (raw)
In-Reply-To: <20251107101003.GB1618871@noisy.programming.kicks-ass.net>

On Fri, 7 Nov 2025 at 11:10, Peter Zijlstra <peterz@infradead.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.

  reply	other threads:[~2025-11-07 10:17 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-29 21:03 [PATCH v11 0/9] x86: Enable Linear Address Space Separation support Sohil Mehta
2025-10-29 21:03 ` [PATCH v11 1/9] x86/cpufeatures: Enumerate the LASS feature bits Sohil Mehta
2025-10-31 17:03   ` Dave Hansen
2025-10-29 21:03 ` [PATCH v11 2/9] x86/cpu: Add an LASS dependency on SMAP Sohil Mehta
2025-10-31 17:04   ` Dave Hansen
2025-10-29 21:03 ` [PATCH v11 3/9] x86/asm: Introduce inline memcpy and memset Sohil Mehta
2025-10-31 17:06   ` Dave Hansen
2025-10-29 21:03 ` [PATCH v11 4/9] x86/alternatives: Disable LASS when patching kernel code Sohil Mehta
2025-10-31 17:10   ` Dave Hansen
2025-11-10 18:15   ` Sohil Mehta
2025-11-10 19:09     ` H. Peter Anvin
2025-11-10 19:24     ` Borislav Petkov
2025-11-12 13:56     ` Ard Biesheuvel
2025-11-12 14:51       ` Dave Hansen
2025-11-12 14:57         ` H. Peter Anvin
2025-11-12 15:18           ` Ard Biesheuvel
2025-11-12 15:23             ` H. Peter Anvin
2025-11-12 15:28               ` Ard Biesheuvel
2025-11-12 15:47                 ` H. Peter Anvin
2025-11-12 16:18                 ` Sohil Mehta
2025-11-12 16:26                   ` H. Peter Anvin
2025-11-12 16:29                   ` H. Peter Anvin
2025-10-29 21:03 ` [PATCH v11 5/9] x86/efi: Disable LASS while mapping the EFI runtime services Sohil Mehta
2025-10-31 17:11   ` Dave Hansen
2025-10-31 17:38     ` Andy Lutomirski
2025-10-31 17:41       ` Dave Hansen
2025-10-31 18:03         ` Sohil Mehta
2025-10-31 18:12           ` Dave Hansen
2025-11-07  9:04             ` Peter Zijlstra
2025-11-07  9:22               ` Ard Biesheuvel
2025-11-07  9:27                 ` H. Peter Anvin
2025-11-07  9:35                   ` Ard Biesheuvel
2025-11-07  9:40                 ` Peter Zijlstra
2025-11-07 10:09                   ` Ard Biesheuvel
2025-11-07 10:27                     ` Peter Zijlstra
2025-11-08  0:48                     ` Andy Lutomirski
2025-11-08 16:18                       ` H. Peter Anvin
2025-11-08 22:50                       ` H. Peter Anvin
2025-11-07 10:10                 ` Peter Zijlstra
2025-11-07 10:17                   ` Ard Biesheuvel [this message]
2025-10-31 19:04       ` Sohil Mehta
2025-11-07  7:36         ` Sohil Mehta
2025-10-31 18:32     ` Sohil Mehta
2025-10-29 21:03 ` [PATCH v11 6/9] x86/kexec: Disable LASS during relocate kernel Sohil Mehta
2025-10-31 17:14   ` Dave Hansen
2025-10-29 21:03 ` [PATCH v11 7/9] x86/traps: Communicate a LASS violation in #GP message Sohil Mehta
2025-10-31 17:16   ` Dave Hansen
2025-10-31 19:59     ` Sohil Mehta
2025-10-31 20:03       ` Andy Lutomirski
2025-10-31 20:56       ` Dave Hansen
2025-10-29 21:03 ` [PATCH v11 8/9] selftests/x86: Update the negative vsyscall tests to expect a #GP Sohil Mehta
2025-10-31 17:20   ` Dave Hansen
2025-10-29 21:03 ` [PATCH v11 9/9] x86/cpu: Enable LASS by default during CPU initialization Sohil Mehta
2025-10-30  8:40   ` H. Peter Anvin
2025-10-30 15:45     ` Andy Lutomirski
2025-10-30 16:44       ` Sohil Mehta
2025-10-30 16:53         ` Andy Lutomirski
2025-10-30 17:24           ` Sohil Mehta
2025-10-30 17:31             ` Andy Lutomirski
2025-10-30 21:13         ` David Laight
2025-10-31  6:41           ` H. Peter Anvin
2025-10-31 16:55           ` Dave Hansen
2025-10-30 16:27     ` Dave Hansen
2025-11-07  8:01       ` H. Peter Anvin
2025-11-07 20:08         ` Sohil Mehta
2025-10-31 17:21   ` Dave Hansen
2025-10-31 20:04     ` Sohil Mehta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMj1kXHFQYN8QF5Sd4ObsCziM-0gitGS5D1S1qCscKpQaZVDLA@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dwmw@amazon.co.uk \
    --cc=geert@linux-m68k.org \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@kernel.org \
    --cc=kas@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=seanjc@google.com \
    --cc=sohil.mehta@intel.com \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vegard.nossum@oracle.com \
    --cc=x86@kernel.org \
    --cc=xin@zytor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).