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

Message-ID: <20260128131153.GW1134360@nvidia.com>
Date: Wed, 28 Jan 2026 09:11:53 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: "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

On Wed, Jan 28, 2026 at 12:57:59AM +0000, Tian, Kevin wrote:
> > > - 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.
> 
> It was made that way by commit 5518f239aff1 ("iommu/vt-d: Move
> scalable mode ATS enablement to probe path "). The old policy was
> same as AMD side, and changed to current way so domain change 
> in RID won't affect the ATS requirement for PASIDs.

That's a legimiate thing, but always on is a heavy handed solution.

The driver should track what is going on with the PASID and enable ATS
if required.

Which also solves this:

> there is one scenario, e.g. VFIO allows domains attached to RID and
> PASIDs being changed independently. It's a sane situation to have
> userspace change RID domain via attach/detach/re-attach, while
> PASID domains are still active. 'detach' will attach RID to a BLOCKED
> domain, then disabling ATS in that window may break PASIDs.
 
> How does ARM address this scenario? Is it more suitable to have
> a new interface specific for driver bind/unbind to enable/disable
> ATS instead of toggling it based on BLOCKED?

And is what SMMUv3 is doing already. With an IDENTITY translation on
the RID it starts out with ATS disabled and switches to IDENTITY with
ATS enabled when the first PASID appears. Switches back when the PASID
goes away.

Jason