linux-kernel - [PATCH v2] Intel IOMMU patch to reprocess RMRR info

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

Message-Id: <20120918172807.12439.93299.sendpatchset@tmingo.houston.hp.com>
Date:	Tue, 18 Sep 2012 17:27:56 +0000 (UTC)
From:	Tom Mingarelli <thomas.mingarelli@...com>
To:	Alex Williamson <alex.williamson@...hat.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Don Dutile <ddutile@...hat.com>
Cc:	Shuah Khan <shuah.khan@...com>,
	Tom Mingarelli <thomas.mingarelli@...com>,
	Linda Knippers <linda.knippers@...com>,
	iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: [PATCH v2] Intel IOMMU patch to reprocess RMRR info

When a 32bit PCI device is removed from the SI Domain, the RMRR information
for this device becomes invalid and needs to be reprocessed to avoid DMA
Read errors. These errors are evidenced by the Present bit being cleared in
the device's context entry. Fixing this problem with an enhancement to process
the RMRR info when the device is assigned to another domain. The Bus Master bit
is cleared during the move to another domain and during the reprocessing of
the RMRR info so no DMA can take place at this time.
----
PATCH v1: https://lkml.org/lkml/2012/6/15/204

drivers/iommu/intel-iommu.c |   47 ++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 44 insertions(+), 3 deletions(-)

Signed-off-by: Thomas Mingarelli <thomas.mingarelli@...com>

diff -up ./drivers/iommu/intel-iommu.c.ORIG ./drivers/iommu/intel-iommu.c
--- ./drivers/iommu/intel-iommu.c.ORIG	2012-09-18 09:58:25.147976889 -0500
+++ ./drivers/iommu/intel-iommu.c	2012-09-18 10:39:43.286672765 -0500
@@ -2706,11 +2706,39 @@ static int iommu_dummy(struct pci_dev *p
 	return pdev->dev.archdata.iommu == DUMMY_DEVICE_DOMAIN_INFO;
 }
 
+static int reprocess_rmrr(struct device *dev)
+{
+	struct dmar_rmrr_unit *rmrr;
+	struct pci_dev *pdev;
+	int i, ret;
+
+	pdev = to_pci_dev(dev);
+
+	for_each_rmrr_units(rmrr) {
+		for (i = 0; i < rmrr->devices_cnt; i++) {
+			/*
+			 * Here we are just concerned with
+			 * finding the one device that was
+			 * removed from the si_domain and
+			 * re-evaluating its RMRR info.
+			 */
+			if (rmrr->devices[i] != pdev)
+				continue;
+			pr_info("IOMMU: Reprocess RMRR information for device %s.\n",
+				pci_name(pdev));
+			ret = iommu_prepare_rmrr_dev(rmrr, pdev);
+			if (ret)
+				pr_err("IOMMU: Reprocessing RMRR reserved region for device failed");
+		}
+	}
+return 0;
+}
+
 /* Check if the pdev needs to go through non-identity map and unmap process.*/
 static int iommu_no_mapping(struct device *dev)
 {
 	struct pci_dev *pdev;
-	int found;
+	int found, current_bus_master;
 
 	if (unlikely(dev->bus != &pci_bus_type))
 		return 1;
@@ -2731,9 +2759,22 @@ static int iommu_no_mapping(struct devic
 			 * 32 bit DMA is removed from si_domain and fall back
 			 * to non-identity mapping.
 			 */
-			domain_remove_one_dev_info(si_domain, pdev);
 			printk(KERN_INFO "32bit %s uses non-identity mapping\n",
-			       pci_name(pdev));
+				pci_name(pdev));
+			/*
+			 * If a device gets this far we need to clear the Bus
+			 * Master bit before we start moving devices from domain
+			 * to domain. We will also reset the Bus Master bit
+			 * after reprocessing the RMRR info. However, we only
+			 * do both the clearing and setting if needed.
+			 */
+			current_bus_master = pdev->is_busmaster;
+			if (current_bus_master)
+				pci_clear_master(pdev);
+			domain_remove_one_dev_info(si_domain, pdev);
+			reprocess_rmrr(dev);
+			if (current_bus_master)
+				pci_set_master(pdev);
 			return 0;
 		}
 	} else {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/