2019-11-07 18:04:08 +00:00
|
|
|
From: "Gomez Iglesias, Antonio" <antonio.gomez.iglesias@intel.com>
|
|
|
|
Date: Mon, 4 Nov 2019 12:22:03 +0100
|
|
|
|
Subject: Documentation: Add ITLB_MULTIHIT documentation
|
|
|
|
|
2019-11-09 20:16:45 +00:00
|
|
|
commit 7f00cc8d4a51074eb0ad4c3f16c15757b1ddfb7d upstream
|
2019-11-07 18:04:08 +00:00
|
|
|
|
|
|
|
Add the initial ITLB_MULTIHIT documentation.
|
|
|
|
|
|
|
|
[ tglx: Add it to the index so it gets actually built. ]
|
|
|
|
|
|
|
|
Signed-off-by: Antonio Gomez Iglesias <antonio.gomez.iglesias@intel.com>
|
|
|
|
Signed-off-by: Nelson D'Souza <nelson.dsouza@linux.intel.com>
|
|
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
|
|
---
|
|
|
|
Documentation/admin-guide/hw-vuln/index.rst | 1 +
|
|
|
|
.../admin-guide/hw-vuln/multihit.rst | 163 ++++++++++++++++++
|
|
|
|
2 files changed, 164 insertions(+)
|
|
|
|
create mode 100644 Documentation/admin-guide/hw-vuln/multihit.rst
|
|
|
|
|
|
|
|
--- a/Documentation/admin-guide/hw-vuln/index.rst
|
|
|
|
+++ b/Documentation/admin-guide/hw-vuln/index.rst
|
|
|
|
@@ -13,3 +13,4 @@ are configurable at compile, boot or run
|
|
|
|
l1tf
|
|
|
|
mds
|
|
|
|
tsx_async_abort
|
|
|
|
+ multihit.rst
|
|
|
|
--- /dev/null
|
|
|
|
+++ b/Documentation/admin-guide/hw-vuln/multihit.rst
|
|
|
|
@@ -0,0 +1,163 @@
|
|
|
|
+iTLB multihit
|
|
|
|
+=============
|
|
|
|
+
|
|
|
|
+iTLB multihit is an erratum where some processors may incur a machine check
|
|
|
|
+error, possibly resulting in an unrecoverable CPU lockup, when an
|
|
|
|
+instruction fetch hits multiple entries in the instruction TLB. This can
|
|
|
|
+occur when the page size is changed along with either the physical address
|
|
|
|
+or cache type. A malicious guest running on a virtualized system can
|
|
|
|
+exploit this erratum to perform a denial of service attack.
|
|
|
|
+
|
|
|
|
+
|
|
|
|
+Affected processors
|
|
|
|
+-------------------
|
|
|
|
+
|
|
|
|
+Variations of this erratum are present on most Intel Core and Xeon processor
|
|
|
|
+models. The erratum is not present on:
|
|
|
|
+
|
|
|
|
+ - non-Intel processors
|
|
|
|
+
|
|
|
|
+ - Some Atoms (Airmont, Bonnell, Goldmont, GoldmontPlus, Saltwell, Silvermont)
|
|
|
|
+
|
|
|
|
+ - Intel processors that have the PSCHANGE_MC_NO bit set in the
|
|
|
|
+ IA32_ARCH_CAPABILITIES MSR.
|
|
|
|
+
|
|
|
|
+
|
|
|
|
+Related CVEs
|
|
|
|
+------------
|
|
|
|
+
|
|
|
|
+The following CVE entry is related to this issue:
|
|
|
|
+
|
|
|
|
+ ============== =================================================
|
|
|
|
+ CVE-2018-12207 Machine Check Error Avoidance on Page Size Change
|
|
|
|
+ ============== =================================================
|
|
|
|
+
|
|
|
|
+
|
|
|
|
+Problem
|
|
|
|
+-------
|
|
|
|
+
|
|
|
|
+Privileged software, including OS and virtual machine managers (VMM), are in
|
|
|
|
+charge of memory management. A key component in memory management is the control
|
|
|
|
+of the page tables. Modern processors use virtual memory, a technique that creates
|
|
|
|
+the illusion of a very large memory for processors. This virtual space is split
|
|
|
|
+into pages of a given size. Page tables translate virtual addresses to physical
|
|
|
|
+addresses.
|
|
|
|
+
|
|
|
|
+To reduce latency when performing a virtual to physical address translation,
|
|
|
|
+processors include a structure, called TLB, that caches recent translations.
|
|
|
|
+There are separate TLBs for instruction (iTLB) and data (dTLB).
|
|
|
|
+
|
|
|
|
+Under this errata, instructions are fetched from a linear address translated
|
|
|
|
+using a 4 KB translation cached in the iTLB. Privileged software modifies the
|
|
|
|
+paging structure so that the same linear address using large page size (2 MB, 4
|
|
|
|
+MB, 1 GB) with a different physical address or memory type. After the page
|
|
|
|
+structure modification but before the software invalidates any iTLB entries for
|
|
|
|
+the linear address, a code fetch that happens on the same linear address may
|
|
|
|
+cause a machine-check error which can result in a system hang or shutdown.
|
|
|
|
+
|
|
|
|
+
|
|
|
|
+Attack scenarios
|
|
|
|
+----------------
|
|
|
|
+
|
|
|
|
+Attacks against the iTLB multihit erratum can be mounted from malicious
|
|
|
|
+guests in a virtualized system.
|
|
|
|
+
|
|
|
|
+
|
|
|
|
+iTLB multihit system information
|
|
|
|
+--------------------------------
|
|
|
|
+
|
|
|
|
+The Linux kernel provides a sysfs interface to enumerate the current iTLB
|
|
|
|
+multihit status of the system:whether the system is vulnerable and which
|
|
|
|
+mitigations are active. The relevant sysfs file is:
|
|
|
|
+
|
|
|
|
+/sys/devices/system/cpu/vulnerabilities/itlb_multihit
|
|
|
|
+
|
|
|
|
+The possible values in this file are:
|
|
|
|
+
|
|
|
|
+.. list-table::
|
|
|
|
+
|
|
|
|
+ * - Not affected
|
|
|
|
+ - The processor is not vulnerable.
|
|
|
|
+ * - KVM: Mitigation: Split huge pages
|
|
|
|
+ - Software changes mitigate this issue.
|
|
|
|
+ * - KVM: Vulnerable
|
|
|
|
+ - The processor is vulnerable, but no mitigation enabled
|
|
|
|
+
|
|
|
|
+
|
|
|
|
+Enumeration of the erratum
|
|
|
|
+--------------------------------
|
|
|
|
+
|
|
|
|
+A new bit has been allocated in the IA32_ARCH_CAPABILITIES (PSCHANGE_MC_NO) msr
|
|
|
|
+and will be set on CPU's which are mitigated against this issue.
|
|
|
|
+
|
|
|
|
+ ======================================= =========== ===============================
|
|
|
|
+ IA32_ARCH_CAPABILITIES MSR Not present Possibly vulnerable,check model
|
|
|
|
+ IA32_ARCH_CAPABILITIES[PSCHANGE_MC_NO] '0' Likely vulnerable,check model
|
|
|
|
+ IA32_ARCH_CAPABILITIES[PSCHANGE_MC_NO] '1' Not vulnerable
|
|
|
|
+ ======================================= =========== ===============================
|
|
|
|
+
|
|
|
|
+
|
|
|
|
+Mitigation mechanism
|
|
|
|
+-------------------------
|
|
|
|
+
|
|
|
|
+This erratum can be mitigated by restricting the use of large page sizes to
|
|
|
|
+non-executable pages. This forces all iTLB entries to be 4K, and removes
|
|
|
|
+the possibility of multiple hits.
|
|
|
|
+
|
|
|
|
+In order to mitigate the vulnerability, KVM initially marks all huge pages
|
|
|
|
+as non-executable. If the guest attempts to execute in one of those pages,
|
|
|
|
+the page is broken down into 4K pages, which are then marked executable.
|
|
|
|
+
|
|
|
|
+If EPT is disabled or not available on the host, KVM is in control of TLB
|
|
|
|
+flushes and the problematic situation cannot happen. However, the shadow
|
|
|
|
+EPT paging mechanism used by nested virtualization is vulnerable, because
|
|
|
|
+the nested guest can trigger multiple iTLB hits by modifying its own
|
|
|
|
+(non-nested) page tables. For simplicity, KVM will make large pages
|
|
|
|
+non-executable in all shadow paging modes.
|
|
|
|
+
|
|
|
|
+Mitigation control on the kernel command line and KVM - module parameter
|
|
|
|
+------------------------------------------------------------------------
|
|
|
|
+
|
|
|
|
+The KVM hypervisor mitigation mechanism for marking huge pages as
|
|
|
|
+non-executable can be controlled with a module parameter "nx_huge_pages=".
|
|
|
|
+The kernel command line allows to control the iTLB multihit mitigations at
|
|
|
|
+boot time with the option "kvm.nx_huge_pages=".
|
|
|
|
+
|
|
|
|
+The valid arguments for these options are:
|
|
|
|
+
|
|
|
|
+ ========== ================================================================
|
|
|
|
+ force Mitigation is enabled. In this case, the mitigation implements
|
|
|
|
+ non-executable huge pages in Linux kernel KVM module. All huge
|
|
|
|
+ pages in the EPT are marked as non-executable.
|
|
|
|
+ If a guest attempts to execute in one of those pages, the page is
|
|
|
|
+ broken down into 4K pages, which are then marked executable.
|
|
|
|
+
|
|
|
|
+ off Mitigation is disabled.
|
|
|
|
+
|
|
|
|
+ auto Enable mitigation only if the platform is affected and the kernel
|
|
|
|
+ was not booted with the "mitigations=off" command line parameter.
|
|
|
|
+ This is the default option.
|
|
|
|
+ ========== ================================================================
|
|
|
|
+
|
|
|
|
+
|
|
|
|
+Mitigation selection guide
|
|
|
|
+--------------------------
|
|
|
|
+
|
|
|
|
+1. No virtualization in use
|
|
|
|
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
+
|
|
|
|
+ The system is protected by the kernel unconditionally and no further
|
|
|
|
+ action is required.
|
|
|
|
+
|
|
|
|
+2. Virtualization with trusted guests
|
|
|
|
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
+
|
|
|
|
+ If the guest comes from a trusted source, you may assume that the guest will
|
|
|
|
+ not attempt to maliciously exploit these errata and no further action is
|
|
|
|
+ required.
|
|
|
|
+
|
|
|
|
+3. Virtualization with untrusted guests
|
|
|
|
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
+ If the guest comes from an untrusted source, the guest host kernel will need
|
|
|
|
+ to apply iTLB multihit mitigation via the kernel command line or kvm
|
|
|
|
+ module parameter.
|