Message-ID: <69b9a009-55bb-4330-b64a-99b20bd9abef@arm.com>
Date: Wed, 4 Feb 2026 12:18:15 +0000
From: Robin Murphy <robin.murphy@....com>
To: Jason Gunthorpe <jgg@...dia.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 2026-02-03 11:16 pm, Jason Gunthorpe wrote:
> 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.

I know, but you brought up require_direct so I figured it was worth 
clarifying that should not in fact impact ATS decisions, since the 
combination a device requiring ATS while *also* requiring an RMR would 
be essentially impossible to support given the SMMU architecture, thus 
we can reasonably assume nobody will do such a thing (or at least do it 
with any expectation of it ever working).

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

Pre-boot protection is in the same boat, as things currently stand - an 
OS could either preserve security (by using GBPA to keep traffic blocked 
while reconfiguring the rest of the SMMU), *or* have ongoing DMA for a 
splash screen or whatever; it cannot realistically have both.

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

Yes, I think the only valid case for having an RMR and expecting it to 
work in combination with these other things is if the device has some 
firmware or preloaded configuration in memory which it will still need 
to access at that address once an OS driver starts using it, but does 
not need to access *during* the boot-time handover. Thus it seems fair 
to still honour the reserved regions upon attaching to a default domain, 
but not worry too much about being in a transient blocking state in the 
interim if it's unavoidable for other reasons (at worst maybe just log a 
warning that we're doing so).

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

Only if you assume DVM or some other mechanism for the guest to issue S1 
invalidations directly to the hardware - with an emulated CMDQ we can do 
whatever we like.

And in fact, I think we actually *have* to if the host has enabled ATS 
itself, since we cannot assume that a guest is going to choose to use 
it, thus we cannot rely on the guest issuing ATCIs in order to get the 
correct behaviour it expects unless and until we've seen it set EATS 
appropriately in all the corresponding vSTEs. So we would have to forbid 
DVM, and only allow other direct mechanisms that can be dynamically 
enabled for as long as the guest configuration matches... Fun.

Thanks,
Robin.

Powered by blists - more mailing lists