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: <BN9PR11MB527649A0049CA195E7BCF9218C90A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Tue, 27 Jan 2026 08:10:06 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: "Williams, Dan J" <dan.j.williams@...el.com>, Jason Gunthorpe
	<jgg@...dia.com>
CC: 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

> From: Williams, Dan J <dan.j.williams@...el.com>
> Sent: Friday, January 23, 2026 3:46 AM
> 
> Jason Gunthorpe wrote:
> > On Wed, Jan 21, 2026 at 09:44:32PM -0800, dan.j.williams@...el.com
> wrote:
> > > I do not immediately see what is wrong with requiring userspace policy
> > > opt-in. That naturally gets replaced by installing the device's
> > > certificate (for native PCI CMA), authenticating the device with the
> > > TSM (for PCI IDE), or obviated by secure-ATS if that arrives.
> >
> > I think that goes back to the discussion about not loading drivers
> > before validating the device.
> >
> > It would also make alot of sense to leave the IOMMU blocking until the
> > driver is loaded for these secure situations. The blocking translation
> > should block ATS too.
> >
> > Then the flow you are describing will work well:
> >
> > 1) At pre-boot the IOMMU will block all DMA including Translated.
> > 2) The OS activates the IOMMU driver and keeps blocking.
> > 3) Instead of immediately binding a default domain the IOMMU core
> >    leaves the translation blocking.
> > 4) The OS defers loading the driver to userspace.
> > 5) Userspace measures the device and "accepts" it by loading the
> >    driver
> > 6) IOMMU core attaches a non-blocking default domain and activates ATS
> 
> That works for me. Give the paranoid the ability to have a point where they
> can
> be assured that the shields were not lowered prematurely.

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)?

Better to clarity the agreement here as the output decides whether to
continue what this series tries to do...

At a glance cxl.cache devices have gained ATS enabled automatically in
most cases (same as for all other ats-capable PCI devices):

- 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

- AMD: ATS is enabled at domain attach time

- Intel: ATS is enabled when a device is probed by intel-iommu driver
  (incompatible with the suggested flow)

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?