linux-kernel - [PATCH 1/1] iommu/vt-d: Restore previous domain::aperture

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

Message-ID: <20251120072524.3218282-1-baolu.lu@linux.intel.com>
Date: Thu, 20 Nov 2025 15:25:24 +0800
From: Lu Baolu <baolu.lu@...ux.intel.com>
To: Joerg Roedel <joro@...tes.org>,
	Will Deacon <will@...nel.org>,
	Robin Murphy <robin.murphy@....com>,
	Kevin Tian <kevin.tian@...el.com>,
	Jason Gunthorpe <jgg@...dia.com>,
	Chaitanya Kumar Borah <chaitanya.kumar.borah@...el.com>
Cc: iommu@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	Lu Baolu <baolu.lu@...ux.intel.com>
Subject: [PATCH 1/1] iommu/vt-d: Restore previous domain::aperture_end calculation

Commit d373449d8e97 ("iommu/vt-d: Use the generic iommu page table")
changed the calculation of domain::aperture_end. Previously, it was
calculated as:

    domain->domain.geometry.aperture_end =
            __DOMAIN_MAX_ADDR(domain->gaw - 1);

where domain->gaw was limited to less than MGAW.

Currently, it is calculated purely based on the max level of the page
table that the hardware supports. This is incorrect as stated in Section
3.6 of the VT-d spec:

  "Software using first-stage translation structures to translate an IO
   Virtual Address (IOVA) must use canonical addresses. Additionally,
   software must limit addresses to less than the minimum of MGAW and the
   lower canonical address width implied by FSPM (i.e., 47-bit when FSPM
   is 4-level and 56-bit when FSPM is 5-level)."

Restore the previous calculation method for domain::aperture_end to avoid
violating the spec. Incorrect aperture calculation causes GPU hangs
without generating VT-d faults on some Intel client platforms.

Fixes: d373449d8e97 ("iommu/vt-d: Use the generic iommu page table")
Reported-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@...el.com>
Closes: https://lore.kernel.org/r/4f15cf3b-6fad-4cd8-87e5-6d86c0082673@intel.com
Suggested-by: Jason Gunthorpe <jgg@...dia.com>
Suggested-by: Kevin Tian <kevin.tian@...el.com>
Signed-off-by: Lu Baolu <baolu.lu@...ux.intel.com>
---
 drivers/iommu/intel/iommu.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 2d2f64ce2bc6..7b3016491ca5 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -2817,6 +2817,16 @@ intel_iommu_domain_alloc_first_stage(struct device *dev,
 		cfg.common.hw_max_vasz_lg2 = 57;
 	else
 		cfg.common.hw_max_vasz_lg2 = 48;
+
+	/*
+	 * Spec 3.6 First-Stage Translation:
+	 *
+	 * Software must limit addresses to less than the minimum of MGAW
+	 * and the lower canonical address width implied by FSPM (i.e.,
+	 * 47-bit when FSPM is 4-level and 56-bit when FSPM is 5-level).
+	 */
+	cfg.common.hw_max_vasz_lg2 = min(cap_mgaw(iommu->cap),
+					 cfg.common.hw_max_vasz_lg2);
 	cfg.common.hw_max_oasz_lg2 = 52;
 	cfg.common.features = BIT(PT_FEAT_SIGN_EXTEND) |
 			      BIT(PT_FEAT_FLUSH_RANGE);
-- 
2.43.0