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: <20260204132149.GG3931454@nvidia.com>
Date: Wed, 4 Feb 2026 09:21:49 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: dan.j.williams@...el.com, "Tian, Kevin" <kevin.tian@...el.com>,
	Jonathan Cameron <jonathan.cameron@...wei.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 Tue, Feb 03, 2026 at 10:50:39AM -0800, Nicolin Chen wrote:
> On Tue, Feb 03, 2026 at 01:55:40PM -0400, Jason Gunthorpe wrote:
> > On Tue, Feb 03, 2026 at 09:45:17AM -0800, Nicolin Chen wrote:
> > > Btw, attaching to IOMMU_DOMAIN_BLOCKED/group->blocking_domain is not
> > > allowed in general if require_direct=true. I assume this case can be
> > > an exception since there's no point in allowing a device that has no
> > > driver yet to access any reserved region?
> > 
> > If require_direct is set then we have to disable this mechanism..
> > 
> > I'm not sure exactly what to do about this as the require_direct comes
> > from the hypervisor in a CC VM and we probably don't want to give the
> > hypervisor this kind of escape hatch.
> > 
> > Perhaps we need to lock off to failure on CC VMs if this ever
> > happens..
> > 
> > But baremetal should just keep working how it always worked in this
> > case..
> 
> OK. I will put a note in the patch, since it would literally skip
> any VM case at this moment.
> 
> I just realized a corner case, as iommu_probe_device() may attach
> the device to group->domain if it's set:
> https://lore.kernel.org/all/9-v5-1b99ae392328+44574-iommu_err_unwind_jgg@nvidia.com/
> 
> I am not sure about the use case, but I assume we should skip the
> blocking_domain as well in this case?
> 
> Then, this makes the condition be:
> +	if (!dev->driver && !group->domain && !dev->iommu->require_direct) {
> +               ret = __iommu_group_alloc_blocking_domain(group);
> +               if (ret)
> +                       goto err_remove_gdev;
> +               group->domain = group->blocking_domain;
> +	}

Just to be clear this is some other project "DMA boot security" and
IDK if we need to do it until the CC patches land for user space
device binding policy, or someone seriously implements DRTM..

Jason