From: <dan.j.williams@intel.com>
To: Jason Gunthorpe <jgg@nvidia.com>,
Jonathan Cameron <jonathan.cameron@huawei.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
Nicolin Chen <nicolinc@nvidia.com>,
"will@kernel.org" <will@kernel.org>,
"robin.murphy@arm.com" <robin.murphy@arm.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"Williams, Dan J" <dan.j.williams@intel.com>,
"joro@8bytes.org" <joro@8bytes.org>,
"praan@google.com" <praan@google.com>,
"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
"miko.lenczewski@arm.com" <miko.lenczewski@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
<linux-cxl@vger.kernel.org>
Subject: Re: [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
Date: Wed, 21 Jan 2026 21:44:32 -0800 [thread overview]
Message-ID: <6971b9406d069_1d33100df@dwillia2-mobl4.notmuch> (raw)
In-Reply-To: <20260121130315.GE1134360@nvidia.com>
Jason Gunthorpe wrote:
> On Wed, Jan 21, 2026 at 10:03:07AM +0000, Jonathan Cameron wrote:
> > On Wed, 21 Jan 2026 08:01:36 +0000
> > "Tian, Kevin" <kevin.tian@intel.com> wrote:
> >
> > > +Dan. I recalled an offline discussion in which he raised concern on
> > > having the kernel blindly enable ATS for cxl.cache device instead of
> > > creating a knob for admin to configure from userspace (in case
> > > security is viewed more important than functionality, upon allowing
> > > DMA to read data out of CPU caches)...
> > >
> >
> > +CC Linux-cxl
>
> A cxl.cache device supporting ATS will automatically enable ATS today
> if the kernel option to enable translation is set.
>
> Even if the device is marked untrusted by the PCI layer (eg an
> external port).
>
> Yes this is effectively a security issue, but it is not really a CXL
> specific problem.
My contention is that it is a worse or at least different problem in the
CXL case because now you have a new toolkit in an attack that wants to
exfiltrate data from CPU caches.
> We might perfer to not enable ATS for untrusted devices and then fail to
> load drivers for "ats always on" cases.
The current PCI untrusted flag is not fit for purpose in this new age of
PCI device authentication and CXL.cache capable devices.
> Or maybe we can enable one of the ATS security features someday,
> though I wonder if those work for CXL..
It should work, but before that I do not see the justification to say
effectively:
"We have a less than perfect legacy way (PCI untrusted flag) to nod at
ATS security problems. Let us ignore even that for a new class of
devices that advertise they can trigger all the old security problems
plus new ones."
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.
next prev parent reply other threads:[~2026-01-22 5:44 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-17 4:56 [PATCH RFCv1 0/3] Allow ATS to be always on for certain ATS-capable devices Nicolin Chen
2026-01-17 4:56 ` [PATCH RFCv1 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices Nicolin Chen
2026-01-19 17:58 ` Jason Gunthorpe
2026-01-21 8:01 ` Tian, Kevin
2026-01-21 10:03 ` Jonathan Cameron
2026-01-21 13:03 ` Jason Gunthorpe
2026-01-22 1:17 ` Baolu Lu
2026-01-22 13:15 ` Jason Gunthorpe
2026-01-22 5:44 ` dan.j.williams [this message]
2026-01-22 13:14 ` Jason Gunthorpe
2026-01-22 16:29 ` Nicolin Chen
2026-01-22 16:58 ` Jason Gunthorpe
2026-01-22 19:46 ` dan.j.williams
2026-01-27 8:10 ` Tian, Kevin
2026-01-27 15:04 ` Jason Gunthorpe
2026-01-28 0:49 ` dan.j.williams
2026-01-28 13:05 ` Jason Gunthorpe
2026-02-03 5:13 ` Nicolin Chen
2026-02-03 14:33 ` Jason Gunthorpe
2026-02-03 17:45 ` Nicolin Chen
2026-02-03 17:55 ` Jason Gunthorpe
2026-02-03 18:50 ` Nicolin Chen
2026-02-04 13:21 ` Jason Gunthorpe
2026-02-03 18:59 ` Robin Murphy
2026-02-03 19:24 ` Nicolin Chen
2026-02-03 23:16 ` Jason Gunthorpe
2026-02-04 12:18 ` Robin Murphy
2026-02-04 13:20 ` Jason Gunthorpe
2026-02-18 22:56 ` Nicolin Chen
2026-02-19 14:37 ` Jason Gunthorpe
2026-02-19 16:53 ` Nicolin Chen
2026-02-19 17:41 ` Jason Gunthorpe
2026-02-20 4:52 ` Nicolin Chen
2026-02-20 12:50 ` Jason Gunthorpe
2026-02-20 13:22 ` Robin Murphy
2026-02-20 13:51 ` Jason Gunthorpe
2026-02-20 14:45 ` Robin Murphy
2026-02-26 15:10 ` Jason Gunthorpe
2026-02-20 18:49 ` Nicolin Chen
2026-02-24 14:38 ` Jason Gunthorpe
2026-01-28 0:57 ` Tian, Kevin
2026-01-28 13:11 ` Jason Gunthorpe
2026-01-29 3:28 ` Tian, Kevin
2026-01-22 10:24 ` Alejandro Lucero Palau
2026-01-17 4:56 ` [PATCH RFCv1 2/3] PCI: Allow ATS to be always on for non-CXL NVIDIA GPUs Nicolin Chen
2026-01-19 18:00 ` Jason Gunthorpe
2026-01-19 18:09 ` Nicolin Chen
2026-01-17 4:56 ` [PATCH RFCv1 3/3] iommu/arm-smmu-v3: Allow ATS to be always on Nicolin Chen
2026-01-19 20:06 ` Jason Gunthorpe
2026-01-26 12:39 ` Will Deacon
2026-01-26 17:20 ` Jason Gunthorpe
2026-01-26 18:40 ` Nicolin Chen
2026-01-26 19:16 ` Jason Gunthorpe
2026-01-26 18:49 ` Robin Murphy
2026-01-26 19:09 ` Jason Gunthorpe
2026-01-27 13:10 ` Will Deacon
2026-01-27 13:26 ` Robin Murphy
2026-01-27 13:50 ` Will Deacon
2026-01-27 14:49 ` Jason Gunthorpe
2026-01-26 18:21 ` Nicolin Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6971b9406d069_1d33100df@dwillia2-mobl4.notmuch \
--to=dan.j.williams@intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=jonathan.cameron@huawei.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=miko.lenczewski@arm.com \
--cc=nicolinc@nvidia.com \
--cc=praan@google.com \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox