linux-kernel - RE: [PATCH v3 4/5] iommu: Introduce iommu_dev_reset_prepare() and iommu_dev_reset

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

Message-ID: <BN9PR11MB52766E1F39D3C239F046CEA28C34A@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Fri, 15 Aug 2025 09:14:28 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Nicolin Chen <nicolinc@...dia.com>, "robin.murphy@....com"
	<robin.murphy@....com>, "joro@...tes.org" <joro@...tes.org>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>, "jgg@...dia.com"
	<jgg@...dia.com>
CC: "will@...nel.org" <will@...nel.org>, "robin.clark@....qualcomm.com"
	<robin.clark@....qualcomm.com>, "yong.wu@...iatek.com"
	<yong.wu@...iatek.com>, "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
	"angelogioacchino.delregno@...labora.com"
	<angelogioacchino.delregno@...labora.com>, "thierry.reding@...il.com"
	<thierry.reding@...il.com>, "vdumpa@...dia.com" <vdumpa@...dia.com>,
	"jonathanh@...dia.com" <jonathanh@...dia.com>, "rafael@...nel.org"
	<rafael@...nel.org>, "lenb@...nel.org" <lenb@...nel.org>, "Liu, Yi L"
	<yi.l.liu@...el.com>, "baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.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-arm-msm@...r.kernel.org"
	<linux-arm-msm@...r.kernel.org>, "linux-mediatek@...ts.infradead.org"
	<linux-mediatek@...ts.infradead.org>, "linux-tegra@...r.kernel.org"
	<linux-tegra@...r.kernel.org>, "linux-acpi@...r.kernel.org"
	<linux-acpi@...r.kernel.org>, "linux-pci@...r.kernel.org"
	<linux-pci@...r.kernel.org>, "patches@...ts.linux.dev"
	<patches@...ts.linux.dev>, "Jaroszynski, Piotr" <pjaroszynski@...dia.com>,
	"Sethi, Vikram" <vsethi@...dia.com>, "helgaas@...nel.org"
	<helgaas@...nel.org>, "etzhao1900@...il.com" <etzhao1900@...il.com>
Subject: RE: [PATCH v3 4/5] iommu: Introduce iommu_dev_reset_prepare() and
 iommu_dev_reset_done()

> From: Nicolin Chen <nicolinc@...dia.com>
> Sent: Tuesday, August 12, 2025 6:59 AM
> 
[...]
> However, if there is a domain attachment/replacement happening during an
> ongoing reset, ATS routines may be re-activated between the two function
> calls. So, introduce a new pending_reset flag in group_device to defer an
> attachment during a reset, allowing iommu core to cache target domains in
> the SW level while bypassing the driver. The iommu_dev_reset_done() will
> re-attach these soft-attached domains, once the device reset is finished.

attach could fail e.g. when device and domain are incompatible. This
deferred attach (until reset done) makes compatibility check impossible in
the resetting window, given the driver attach_dev callback is not called 
in the normal attach path.

Worse..

> +	/* Shift RID domain back to group->domain */
> +	if (group->domain != group->blocking_domain)
> +		WARN_ON(__iommu_attach_device(group->domain, dev));

..means that an user could trigger WARN_ON() easily if he knows an attach
would fail.

IMHO we may just fail attach request in the resetting window then
WARN_ON above makes sense as it's shifting back to a domain which was 
originally attached to the resetting device.

Not sure any valid case where one would want to attach/replace domain
for a resetting device...