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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <69795d0366a9_1d33100d3@dwillia2-mobl4.notmuch>
Date: Tue, 27 Jan 2026 16:49:07 -0800
From: <dan.j.williams@...el.com>
To: Jason Gunthorpe <jgg@...dia.com>, "Tian, Kevin" <kevin.tian@...el.com>
CC: "Williams, Dan J" <dan.j.williams@...el.com>, Jonathan Cameron
	<jonathan.cameron@...wei.com>, Nicolin Chen <nicolinc@...dia.com>,
	"will@...nel.org" <will@...nel.org>, "robin.murphy@....com"
	<robin.murphy@....com>, "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

Jason Gunthorpe wrote:
[..]
> > Jason described the flow as "for these secure situations", i.e. not a general
> > requirement for cxl.cache, but iiuc Dan may instead want userspace policy
> > opt-in to be default (and with CMA/TSM etc. it gets easier)?
> 
> I think the general strategy has been to push userspace to do security
> decisions before binding drivers. So we have a plan for confidential
> compute VMs, and if there is interest then we can probably re-use that
> plan in all other cases.

Right, if you want to configure a kernel to automatically enable ATS
that is choice. But, as distros get more security concious about devices
for confidential compute, it would be nice to be able to rely on the
same opt-in model for other security concerns like ATS security.

> > At a glance cxl.cache devices have gained ATS enabled automatically in
> > most cases (same as for all other ats-capable PCI devices):
> 
> Yes.
>  
> > - ARM: ATS is enabled automatically when attaching the default domain
> >   to the device in certain configurations, and this series tries to auto
> >   enable it in a missing configuration
> 
> Yes, ARM took the position that ATS should be left disabled for
> IDENTITY both because of SMMU constraints and also because it made
> some sense that you wouldn't want ATS overhead just to get a 1:1
> translation.

Does this mean that ARM already today does not enable ATS until driver
attach, or is incremental work needed for that capability?

> > - AMD: ATS is enabled at domain attach time
> 
> I'd argue this is an error and it should work like ARM
> 
> > - Intel: ATS is enabled when a device is probed by intel-iommu driver
> >   (incompatible with the suggested flow)
> 
> This is definately not a good choice :)
> 
> IMHO it is security required that the IOMMU driver block Translated
> requests while a BLOCKED domain is attached, and while the IOMMU is
> refusing ATS then device's ATS enable should be disabled.
> 
> > Given above already shipped in distributions, probably we have to keep
> > them for compatibility (implying this series makes sense to fix a gap
> > in existing policy), then treat the suggested flow as an enhancement
> > for future?
> 
> I don't think we have a compatability issue here, just a security
> one.
> 
> Drivers need to ensure that ATS is disabled at PCI and Translated
> requestes blocked in IOMMU HW while a BLOCKED domain is attached.

"Drivers" here meaning IOMMU drivers, right?

> Drivers can choose if they want to enable ATS for IDENTITY or not,
> (recommend not for performance and consistency).
> 
> Jason