linux-kernel - [PATCH v1 1/6] iommu: Generic support for RMRs during device release

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: <631ef0483b8d1981d037131d0f342c6970ffc155.1760312540.git.nicolinc@nvidia.com>
Date: Sun, 12 Oct 2025 16:57:37 -0700
From: Nicolin Chen <nicolinc@...dia.com>
To: <joro@...tes.org>, <jgg@...dia.com>, <kevin.tian@...el.com>
CC: <suravee.suthikulpanit@....com>, <will@...nel.org>,
	<robin.murphy@....com>, <sven@...nel.org>, <j@...nau.net>,
	<robin.clark@....qualcomm.com>, <m.szyprowski@...sung.com>,
	<krzk@...nel.org>, <dwmw2@...radead.org>, <baolu.lu@...ux.intel.com>,
	<yong.wu@...iatek.com>, <matthias.bgg@...il.com>,
	<angelogioacchino.delregno@...labora.com>, <tjeznach@...osinc.com>,
	<pjw@...nel.org>, <palmer@...belt.com>, <aou@...s.berkeley.edu>,
	<heiko@...ech.de>, <schnelle@...ux.ibm.com>, <mjrosato@...ux.ibm.com>,
	<orsonzhai@...il.com>, <baolin.wang@...ux.alibaba.com>, <wens@...e.org>,
	<jernej.skrabec@...il.com>, <samuel@...lland.org>,
	<thierry.reding@...il.com>, <jonathanh@...dia.com>,
	<jean-philippe@...aro.org>, <iommu@...ts.linux.dev>,
	<linux-kernel@...r.kernel.org>, <asahi@...ts.linux.dev>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-arm-msm@...r.kernel.org>,
	<linux-samsung-soc@...r.kernel.org>, <linux-mediatek@...ts.infradead.org>,
	<linux-riscv@...ts.infradead.org>, <linux-rockchip@...ts.infradead.org>,
	<linux-s390@...r.kernel.org>, <linux-sunxi@...ts.linux.dev>,
	<linux-tegra@...r.kernel.org>, <virtualization@...ts.linux.dev>,
	<patches@...ts.linux.dev>
Subject: [PATCH v1 1/6] iommu: Generic support for RMRs during device release

From: Jason Gunthorpe <jgg@...dia.com>

Generally an IOMMU driver should leave the translation as BLOCKED until the
translation entry is probed onto a struct device. When the struct device is
removed, the translation should be put back to BLOCKED.

Drivers that are able to work like this can set their release_domain to the
blocking domain, and the core code handles this work.

The exception is when the device has an IOMMU_RESV_DIRECT region, in which
case the OS should continuously allow translations for the given range. And
the core code generally prevents using a BLOCKED domain with this device.

Continue this logic for the device release and hoist some open coding from
drivers. If the device has dev->iommu->require_direct and the driver uses a
BLOCKED release_domain, override it to IDENTITY to preserve the semantics.

The only remaining required driver code for IOMMU_RESV_DIRECT should preset
an IDENTITY translation during early IOMMU startup for those devices.

Signed-off-by: Jason Gunthorpe <jgg@...dia.com>
Signed-off-by: Nicolin Chen <nicolinc@...dia.com>
---
 drivers/iommu/iommu.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 59244c744eabd..adef1a37f9311 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -542,8 +542,20 @@ static void iommu_deinit_device(struct device *dev)
 	 * Regardless, if a delayed attach never occurred, then the release
 	 * should still avoid touching any hardware configuration either.
 	 */
-	if (!dev->iommu->attach_deferred && ops->release_domain)
-		ops->release_domain->ops->attach_dev(ops->release_domain, dev);
+	if (!dev->iommu->attach_deferred && ops->release_domain) {
+		struct iommu_domain *release_domain = ops->release_domain;
+
+		/*
+		 * If the device requires direct mappings then it should not
+		 * be parked on a BLOCKED domain during release as that would
+		 * break the direct mappings.
+		 */
+		if (dev->iommu->require_direct && ops->identity_domain &&
+		    release_domain == ops->blocked_domain)
+			release_domain = ops->identity_domain;
+
+		release_domain->ops->attach_dev(release_domain, dev);
+	}
 
 	if (ops->release_device)
 		ops->release_device(dev);
-- 
2.43.0