linux-kernel - Re: [PATCH v9 10/13] cxl: Enable AMD Zen5 address translation using ACPI PRMT

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] [day] [month] [year] [list]

Message-ID: <CAMj1kXENYZq-UkCup6FSH_4tmpRe4xJN1_veuSWs-hxxAo=1Ew@mail.gmail.com>
Date: Thu, 15 Jan 2026 09:30:10 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Jonathan Cameron <jonathan.cameron@...wei.com>, Robert Richter <rrichter@....com>, 
	Alison Schofield <alison.schofield@...el.com>, Vishal Verma <vishal.l.verma@...el.com>, 
	Ira Weiny <ira.weiny@...el.com>, Dan Williams <dan.j.williams@...el.com>, 
	Dave Jiang <dave.jiang@...el.com>, Davidlohr Bueso <dave@...olabs.net>, linux-cxl@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Gregory Price <gourry@...rry.net>, 
	"Fabio M. De Francesco" <fabio.m.de.francesco@...ux.intel.com>, Terry Bowman <terry.bowman@....com>, 
	Joshua Hahn <joshua.hahnjy@...il.com>
Subject: Re: [PATCH v9 10/13] cxl: Enable AMD Zen5 address translation using
 ACPI PRMT

On Thu, 15 Jan 2026 at 09:04, Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Wed, Jan 14, 2026 at 06:08:59PM +0000, Jonathan Cameron wrote:
>
> > Do we have a potential issue wrt to merging this as it stands and improving
> > on it later?  i.e. Is this a blocking issue for this patch set?
>
> Well, why do you *have* to use PRMT at all? And this is a serious
> question; PRMT is basically injecting unaudited magic code into the
> kernel, and that is a security risk.
>
> Worse, in order to run this shit, we have to lower or disable various
> security measures.
>

Only if we decide to keep running it privileged, which the PRM spec no
longer requires (as you have confirmed yourself when we last discussed
this, right?)

> If I had my way, we would WARN and TAINT the kernel whenever such
> garbage got used.

These are things that used to live in SMM, requiring all CPUs to
disappear into SMM mode in a way that was completely opaque to the OS.

PRM runs under the control of the OS, does not require privileges and
only needs MMIO access to the regions it describes in its manifest
(which the OS can inspect, if desired). So if there are security
concerns with PRM today, it is because we were lazy and did not
implement PRM securely from the beginning.

In my defense, I wasn't aware of the unprivileged requirement until
you spotted it recently: it was something I had asked for when the PRM
spec was put up for "review" by the Intel and MS authors, and they
told me they couldn't possibly make any changes at that point, because
it had already gone into production. But as it turns out, the change
was made after all.

I am a total noob when it comes to how x86 does its ring0/ring3
switching, but with some help, I should be able to prototype something
to call into the PRM service unprivileged, running under the efi_mm.

Would that allay your concerns?