50a9ff6df4
The kernel is moved ahead to version 3.10.0-693.21.1.el7 To summarize: CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' This is fixed by load fences and is "baked in" and cannot be turned off. CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' This is fixed by a combination of retpolines and IBPB, or IBRS+IBPB if on skylake. This requires a microcode change in the processors. This feature, if on, has a significant performance impact. It is assumed on unless turned off via the "nospectre_v2" bootarg. CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' This is fixed by page table isolation using the Kaiser patches. This feature is assumed on unless turned off via the "nopti" bootarg. As of the commit date, we have changed the installer kickstarts to issue both "nopti nospectre_v2" bootargs to minimize realtime impacts by default. The customer will be able to optionally sacrifice performance for extra security at datafill time. Change-Id: Id7c99923f2ee2ee91f77c7bd9940e684eff8b476 Signed-off-by: Jim Somerville <Jim.Somerville@windriver.com>
121 lines
5.2 KiB
Diff
121 lines
5.2 KiB
Diff
From 4fb8df1ee9468d9cc67c41d14a5d8ab6bb45ac8a Mon Sep 17 00:00:00 2001
|
|
Message-Id: <4fb8df1ee9468d9cc67c41d14a5d8ab6bb45ac8a.1522097754.git.Jim.Somerville@windriver.com>
|
|
In-Reply-To: <f4706beaf86081b0890ea616082913f8f51823ff.1522097754.git.Jim.Somerville@windriver.com>
|
|
References: <f4706beaf86081b0890ea616082913f8f51823ff.1522097754.git.Jim.Somerville@windriver.com>
|
|
From: Matt Peters <matt.peters@windriver.com>
|
|
Date: Mon, 30 May 2016 10:51:02 -0400
|
|
Subject: [PATCH 08/27] intel-iommu: allow ignoring Ethernet device RMRR with
|
|
IOMMU passthrough
|
|
|
|
Some BIOS's are reporting DMAR RMRR entries for Ethernet devices
|
|
which is causing problems when PCI passthrough is enabled. These
|
|
devices should be able to use the static identity map since the
|
|
host should not be enforcing specific address ranges when IOMMU
|
|
passthrough is enabled.
|
|
|
|
Originally-by: Matt Peters <matt.peters@windriver.com>
|
|
[PG: Added bootarg wrapper and documentation entries.]
|
|
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Signed-off-by: Nam Ninh <nam.ninh@windriver.com>
|
|
|
|
Signed-off-by: Nam Ninh <nam.ninh@windriver.com>
|
|
Signed-off-by: Jim Somerville <Jim.Somerville@windriver.com>
|
|
---
|
|
Documentation/Intel-IOMMU.txt | 18 ++++++++++++++++++
|
|
Documentation/kernel-parameters.txt | 5 +++++
|
|
drivers/iommu/intel-iommu.c | 19 +++++++++++++++++++
|
|
3 files changed, 42 insertions(+)
|
|
|
|
diff --git a/Documentation/Intel-IOMMU.txt b/Documentation/Intel-IOMMU.txt
|
|
index cf9431d..1dcc349 100644
|
|
--- a/Documentation/Intel-IOMMU.txt
|
|
+++ b/Documentation/Intel-IOMMU.txt
|
|
@@ -32,6 +32,24 @@ regions will fail. Hence BIOS uses RMRR to specify these regions along with
|
|
devices that need to access these regions. OS is expected to setup
|
|
unity mappings for these regions for these devices to access these regions.
|
|
|
|
+RMRR for other devices?
|
|
+-----------------------
|
|
+
|
|
+There are reports of BIOS out there that indicate RMRR regions for things
|
|
+like ethernet devices. As per mainline commit c875d2c1b8083 ("iommu/vt-d:
|
|
+ Exclude devices using RMRRs from IOMMU API domains") such a device is
|
|
+"fundamentally incompatible" with the IOMMU API and "we must prevent such
|
|
+devices from being used by the IOMMU API." However, in the event that
|
|
+the RMRR indicated by the BIOS is assumed to be just a reporting error,
|
|
+there is an additional iommu boot arg that can be used to ignore RMRR
|
|
+settings for ethernet, i.e. "intel_iommu=on,eth_no_rmrr iommu=pt".
|
|
+Note that iommu=pt is required in order to eth_no_rmrr to have effect.
|
|
+
|
|
+If you use this setting, you should consult with your hardware vendor to
|
|
+confirm that it is just a reporting error, and that it truly is not
|
|
+actively using any DMA to/from RMRR, as otherwise system instability
|
|
+may result.
|
|
+
|
|
How is IOVA generated?
|
|
---------------------
|
|
|
|
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
|
|
index deaafbf..b06a8fb 100644
|
|
--- a/Documentation/kernel-parameters.txt
|
|
+++ b/Documentation/kernel-parameters.txt
|
|
@@ -1264,6 +1264,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|
than 32-bit addressing. The default is to look
|
|
for translation below 32-bit and if not available
|
|
then look in the higher range.
|
|
+ eth_no_rmrr [Default Off]
|
|
+ With this option provided, the kernel will ignore
|
|
+ any specified RMRR regions specified by the BIOS
|
|
+ for PCI ethernet devices. Confirm with your hardware
|
|
+ vendor the RMRR regions are indeed invalid first.
|
|
strict [Default Off]
|
|
With this option on every unmap_single operation will
|
|
result in a hardware IOTLB flush operation as opposed
|
|
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
|
|
index 171a8b2..e763e78 100644
|
|
--- a/drivers/iommu/intel-iommu.c
|
|
+++ b/drivers/iommu/intel-iommu.c
|
|
@@ -496,6 +496,7 @@ static int dmar_forcedac;
|
|
static int intel_iommu_strict;
|
|
static int intel_iommu_superpage = 1;
|
|
static int intel_iommu_ecs = 1;
|
|
+static int intel_iommu_ethrmrr = 1;
|
|
|
|
/* We only actually use ECS when PASID support (on the new bit 40)
|
|
* is also advertised. Some early implementations — the ones with
|
|
@@ -555,6 +556,15 @@ static int __init intel_iommu_setup(char *str)
|
|
} else if (!strncmp(str, "forcedac", 8)) {
|
|
pr_info("Forcing DAC for PCI devices\n");
|
|
dmar_forcedac = 1;
|
|
+ } else if (!strncmp(str, "eth_no_rmrr", 11)) {
|
|
+ if (!iommu_pass_through) {
|
|
+ printk(KERN_WARNING
|
|
+ "Intel-IOMMU: error - eth_no_rmrr requires iommu=pt\n");
|
|
+ } else {
|
|
+ printk(KERN_INFO
|
|
+ "Intel-IOMMU: ignoring ethernet RMRR values\n");
|
|
+ intel_iommu_ethrmrr = 0;
|
|
+ }
|
|
} else if (!strncmp(str, "strict", 6)) {
|
|
pr_info("Disable batched IOTLB flush\n");
|
|
intel_iommu_strict = 1;
|
|
@@ -2674,6 +2684,15 @@ static bool device_is_rmrr_locked(struct device *dev)
|
|
|
|
if (IS_USB_DEVICE(pdev) || IS_GFX_DEVICE(pdev))
|
|
return false;
|
|
+ /* As a temporary workaround for issues seen on ProLiant DL380p,
|
|
+ * allow the operator to ignore the RMRR settings for ethernet
|
|
+ * devices. Ideally the end user should contact their vendor
|
|
+ * regarding why there are RMRR, as per mainline c875d2c1b8083
|
|
+ * ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains")
|
|
+ * it seems that these make no sense at all.
|
|
+ */
|
|
+ if ((pdev->class >> 8) == PCI_CLASS_NETWORK_ETHERNET && !intel_iommu_ethrmrr)
|
|
+ return false;
|
|
}
|
|
|
|
return true;
|
|
--
|
|
1.8.3.1
|
|
|