historical-speck.lore.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: speck@linutronix.de
Subject: [MODERATED] [PATCH v9 7/7] NX 7
Date: Sat,  2 Nov 2019 12:27:33 +0100	[thread overview]
Message-ID: <1572694053-3104-8-git-send-email-pbonzini@redhat.com> (raw)
In-Reply-To: <1572694053-3104-1-git-send-email-pbonzini@redhat.com>

From: "Gomez Iglesias, Antonio" <antonio.gomez.iglesias@intel.com>
Subject: [PATCH v9 7/7] Documentation: Add ITLB_MULTIHIT documentation

Add the initial ITLB_MULTIHIT documentation.

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>
 .../admin-guide/hw-vuln/multihit.rst          | 162 ++++++++++++++++++
 1 file changed, 162 insertions(+)
 create mode 100644 Documentation/admin-guide/hw-vuln/multihit.rst

diff --git a/Documentation/admin-guide/hw-vuln/multihit.rst b/Documentation/admin-guide/hw-vuln/multihit.rst
new file mode 100644
index 000000000000..782ecdfd50e5
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/multihit.rst
@@ -0,0 +1,162 @@
+iTLB multihit
+iTLB multihit is an erratum where some processors may incur a machine check
+error, possibly resulting in an unrecoverable CPU hang, 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
+Related CVEs
+The following CVE entry is related to this issue:
+   ==============  =================================================
+   CVE-2018-12207  Machine Check Error Avoidance on Page Size Change
+   ==============  =================================================
+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
+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
+privileged actors running as 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:
+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.
+  ==========  ================================================================
+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.

      parent reply	other threads:[~2019-11-02 11:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-02 11:27 [MODERATED] [PATCH v9 0/7] NX 0 Paolo Bonzini
2019-11-02 11:27 ` [MODERATED] [PATCH v9 1/7] NX 1 Paolo Bonzini
2019-11-02 11:27 ` [MODERATED] [PATCH v9 2/7] NX 2 Paolo Bonzini
2019-11-02 11:27 ` [MODERATED] [PATCH v9 3/7] NX 3 Paolo Bonzini
2019-11-02 11:27 ` [MODERATED] [PATCH v9 4/7] NX 4 Paolo Bonzini
2019-11-03  0:58   ` [MODERATED] " Pawan Gupta
2019-11-02 11:27 ` [MODERATED] [PATCH v9 5/7] NX 5 Paolo Bonzini
2019-11-02 11:27 ` [MODERATED] [PATCH v9 6/7] NX 6 Paolo Bonzini
2019-11-02 11:27 ` Paolo Bonzini [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1572694053-3104-8-git-send-email-pbonzini@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=speck@linutronix.de \
    --subject='Re: [MODERATED] [PATCH v9 7/7] NX 7' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).