linux-kernel - Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices

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: <20260203231607.GE3931454@nvidia.com>
Date: Tue, 3 Feb 2026 19:16:07 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Robin Murphy <robin.murphy@....com>
Cc: Nicolin Chen <nicolinc@...dia.com>, dan.j.williams@...el.com,
	"Tian, Kevin" <kevin.tian@...el.com>,
	Jonathan Cameron <jonathan.cameron@...wei.com>,
	"will@...nel.org" <will@...nel.org>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"joro@...tes.org" <joro@...tes.org>,
	"praan@...gle.com" <praan@...gle.com>,
	"baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
	"miko.lenczewski@....com" <miko.lenczewski@....com>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-cxl@...r.kernel.org" <linux-cxl@...r.kernel.org>
Subject: Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache
 capable devices

On Tue, Feb 03, 2026 at 06:59:35PM +0000, Robin Murphy wrote:
> Realistically this combination cannot exist bare-metal, since if the device
> requires to send ATS TT's to access an RMR then the SMMU would have to be
> enabled pre-boot, so then the RMR means we cannot ever disable it to
> reconfigure, so we'd be stuffed from the start...

This thread has gotten mixed up..

First this series as it is has nothing to do with RMRs.

What the latter part is discussing is a future series to implement
what I think MS calls "boot DMA security". Meaning we don't get into a
position of allowing a device access to OS memory, even through ATS
translated requests, until after userspace has approved the device.

This is something that should combine with Dynamic Root of Trust for
Measurement, as DRTM is much less useful if DMA can mutate the OS code
after the DTRM returns.

It is also meaningful for systems with encrypted PCI where the OS can
measure the PCI device before permitting it access to anything.

So... When we do implement this new security mode, what should it do
if FW attempts to attack the kernel with these nonsensical RMR
configurations? With DRTM we explicitly don't trust the FW for
security anymore, so it is a problem.

I strongly suspect the answer is that RMR has to be ignored in this
more secure mode.

> However I think there would be no point exposing the ATS details to
> the VM to begin with. It's the host's decision to trust the device
> to play in the translated PA space and system cache coherency
> protocol, and no guest would be allowed to mess with those aspects
> either way, so there seems no obvious good reason for them to know
> at all.

If the vSMMU is presented then the guest must be aware of the ATS
because only the guest can generate the ATC invalidations for changes
in the S1.

Without a vSMMU the ATS can be hidden from the guest.

Jason