From: Nelson D'Souza <nelson.dsouza@linux.intel.com>
To: speck@linutronix.de
Subject: [MODERATED] [PATCH] NX documentation
Date: Fri, 1 Nov 2019 18:12:18 -0700 [thread overview]
Message-ID: <20191102011217.GA4934@guptapadev.amr> (raw)
From: "Gomez Iglesias, Antonio" <antonio.gomez.iglesias@intel.com>
Subject: [PATCH] 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>
---
.../admin-guide/hw-vuln/multihit.rst | 147 ++++++++++++++++++
Documentation/x86/multihit.rst | 25 +++
2 files changed, 172 insertions(+)
create mode 100644 Documentation/admin-guide/hw-vuln/multihit.rst
create mode 100644 Documentation/x86/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..c2c9cef23e20
--- /dev/null
+++ b/Documentation/admin-guide/hw-vuln/multihit.rst
@@ -0,0 +1,147 @@
+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
+encounters a TLB multi-hit 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:
+
+ - 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
+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:
+
+/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 pages.
+
+
+Mitigation control on the kernel command line and KVM - module parameter
+------------------------------------------------------------------------
+
+The kernel command line allows to control the iTLB multihit mitigations at boot
+time with the option "kvm.nx_huge_pages=". The KVM hypervisor mitigation
+mechanism for marking huge pages as non-executable can be controlled with a
+module parameter "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.
+ ========== ================================================================
+
+
+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 the iTLB multihit mitigation via the kernel command line or kvm
+ module parameter.
diff --git a/Documentation/x86/multihit.rst b/Documentation/x86/multihit.rst
new file mode 100644
index 000000000000..185f607e0dc1
--- /dev/null
+++ b/Documentation/x86/multihit.rst
@@ -0,0 +1,25 @@
+iTLB multihit
+=============
+
+Overview
+--------
+
+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
+encounters a TLB multi-hit 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.
+
+
+KVM Mitigation strategy
+-----------------------
+
+Mitigation adds a knob to mark huge pages as non-executable. When the
+nx_huge_pages parameter is enabled (and EPT is being used), all huge pages are
+marked 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.
+This is not an issue for shadow paging (except nested EPT), because then the
+host is in control of TLB flushes and the problematic situation cannot happen.
+With nested EPT, again the nested guest can cause problems so we treat shadow
+and direct EPT the same.
--
2.20.1
next reply other threads:[~2019-11-02 1:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-02 1:12 Nelson D'Souza [this message]
2019-11-02 9:12 ` [MODERATED] Re: [PATCH] NX documentation Paolo Bonzini
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191102011217.GA4934@guptapadev.amr \
--to=nelson.dsouza@linux.intel.com \
--cc=speck@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).