1 From foo@baz Tue 14 May 2019 08:29:35 PM CEST
2 From: Thomas Gleixner <tglx@linutronix.de>
3 Date: Tue, 19 Feb 2019 00:02:31 +0100
4 Subject: Documentation: Add MDS vulnerability documentation
6 From: Thomas Gleixner <tglx@linutronix.de>
8 commit 5999bbe7a6ea3c62029532ec84dc06003a1fa258 upstream.
10 Add the initial MDS vulnerability documentation.
12 Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
13 Reviewed-by: Jon Masters <jcm@redhat.com>
14 [bwh: Backported to 4.4:
15 - Drop the index updates
17 Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
18 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
20 Documentation/hw-vuln/mds.rst | 307 ++++++++++++++++++++++++++++++++++++
21 Documentation/kernel-parameters.txt | 2
22 2 files changed, 309 insertions(+)
23 create mode 100644 Documentation/hw-vuln/mds.rst
26 +++ b/Documentation/hw-vuln/mds.rst
28 +MDS - Microarchitectural Data Sampling
29 +======================================
31 +Microarchitectural Data Sampling is a hardware vulnerability which allows
32 +unprivileged speculative access to data which is available in various CPU
38 +This vulnerability affects a wide range of Intel processors. The
39 +vulnerability is not present on:
41 + - Processors from AMD, Centaur and other non Intel vendors
43 + - Older processor models, where the CPU family is < 6
45 + - Some Atoms (Bonnell, Saltwell, Goldmont, GoldmontPlus)
47 + - Intel processors which have the ARCH_CAP_MDS_NO bit set in the
48 + IA32_ARCH_CAPABILITIES MSR.
50 +Whether a processor is affected or not can be read out from the MDS
51 +vulnerability file in sysfs. See :ref:`mds_sys_info`.
53 +Not all processors are affected by all variants of MDS, but the mitigation
54 +is identical for all of them so the kernel treats them as a single
60 +The following CVE entries are related to the MDS vulnerability:
62 + ============== ===== ==============================================
63 + CVE-2018-12126 MSBDS Microarchitectural Store Buffer Data Sampling
64 + CVE-2018-12130 MFBDS Microarchitectural Fill Buffer Data Sampling
65 + CVE-2018-12127 MLPDS Microarchitectural Load Port Data Sampling
66 + ============== ===== ==============================================
71 +When performing store, load, L1 refill operations, processors write data
72 +into temporary microarchitectural structures (buffers). The data in the
73 +buffer can be forwarded to load operations as an optimization.
75 +Under certain conditions, usually a fault/assist caused by a load
76 +operation, data unrelated to the load memory address can be speculatively
77 +forwarded from the buffers. Because the load operation causes a fault or
78 +assist and its result will be discarded, the forwarded data will not cause
79 +incorrect program execution or state changes. But a malicious operation
80 +may be able to forward this speculative data to a disclosure gadget which
81 +allows in turn to infer the value via a cache side channel attack.
83 +Because the buffers are potentially shared between Hyper-Threads cross
84 +Hyper-Thread attacks are possible.
86 +Deeper technical information is available in the MDS specific x86
87 +architecture section: :ref:`Documentation/x86/mds.rst <mds>`.
93 +Attacks against the MDS vulnerabilities can be mounted from malicious non
94 +priviledged user space applications running on hosts or guest. Malicious
95 +guest OSes can obviously mount attacks as well.
97 +Contrary to other speculation based vulnerabilities the MDS vulnerability
98 +does not allow the attacker to control the memory target address. As a
99 +consequence the attacks are purely sampling based, but as demonstrated with
100 +the TLBleed attack samples can be postprocessed successfully.
105 + It's unclear whether attacks through Web-Browsers are possible at
106 + all. The exploitation through Java-Script is considered very unlikely,
107 + but other widely used web technologies like Webassembly could possibly be
113 +MDS system information
114 +-----------------------
116 +The Linux kernel provides a sysfs interface to enumerate the current MDS
117 +status of the system: whether the system is vulnerable, and which
118 +mitigations are active. The relevant sysfs file is:
120 +/sys/devices/system/cpu/vulnerabilities/mds
122 +The possible values in this file are:
124 + ========================================= =================================
125 + 'Not affected' The processor is not vulnerable
127 + 'Vulnerable' The processor is vulnerable,
128 + but no mitigation enabled
130 + 'Vulnerable: Clear CPU buffers attempted' The processor is vulnerable but
131 + microcode is not updated.
132 + The mitigation is enabled on a
136 + 'Mitigation: CPU buffer clear' The processor is vulnerable and the
137 + CPU buffer clearing mitigation is
139 + ========================================= =================================
141 +If the processor is vulnerable then the following information is appended
142 +to the above information:
144 + ======================== ============================================
145 + 'SMT vulnerable' SMT is enabled
146 + 'SMT mitigated' SMT is enabled and mitigated
147 + 'SMT disabled' SMT is disabled
148 + 'SMT Host state unknown' Kernel runs in a VM, Host SMT state unknown
149 + ======================== ============================================
153 +Best effort mitigation mode
154 +^^^^^^^^^^^^^^^^^^^^^^^^^^^
156 + If the processor is vulnerable, but the availability of the microcode based
157 + mitigation mechanism is not advertised via CPUID the kernel selects a best
158 + effort mitigation mode. This mode invokes the mitigation instructions
159 + without a guarantee that they clear the CPU buffers.
161 + This is done to address virtualization scenarios where the host has the
162 + microcode update applied, but the hypervisor is not yet updated to expose
163 + the CPUID to the guest. If the host has updated microcode the protection
164 + takes effect otherwise a few cpu cycles are wasted pointlessly.
166 + The state in the mds sysfs file reflects this situation accordingly.
169 +Mitigation mechanism
170 +-------------------------
172 +The kernel detects the affected CPUs and the presence of the microcode
175 +If a CPU is affected and the microcode is available, then the kernel
176 +enables the mitigation by default. The mitigation can be controlled at boot
177 +time via a kernel command line option. See
178 +:ref:`mds_mitigation_control_command_line`.
180 +.. _cpu_buffer_clear:
185 + The mitigation for MDS clears the affected CPU buffers on return to user
186 + space and when entering a guest.
188 + If SMT is enabled it also clears the buffers on idle entry when the CPU
189 + is only affected by MSBDS and not any other MDS variant, because the
190 + other variants cannot be protected against cross Hyper-Thread attacks.
192 + For CPUs which are only affected by MSBDS the user space, guest and idle
193 + transition mitigations are sufficient and SMT is not affected.
197 +Virtualization mitigation
198 +^^^^^^^^^^^^^^^^^^^^^^^^^
200 + The protection for host to guest transition depends on the L1TF
201 + vulnerability of the CPU:
203 + - CPU is affected by L1TF:
205 + If the L1D flush mitigation is enabled and up to date microcode is
206 + available, the L1D flush mitigation is automatically protecting the
209 + If the L1D flush mitigation is disabled then the MDS mitigation is
210 + invoked explicit when the host MDS mitigation is enabled.
212 + For details on L1TF and virtualization see:
213 + :ref:`Documentation/hw-vuln//l1tf.rst <mitigation_control_kvm>`.
215 + - CPU is not affected by L1TF:
217 + CPU buffers are flushed before entering the guest when the host MDS
218 + mitigation is enabled.
220 + The resulting MDS protection matrix for the host to guest transition:
222 + ============ ===== ============= ============ =================
223 + L1TF MDS VMX-L1FLUSH Host MDS MDS-State
225 + Don't care No Don't care N/A Not affected
227 + Yes Yes Disabled Off Vulnerable
229 + Yes Yes Disabled Full Mitigated
231 + Yes Yes Enabled Don't care Mitigated
233 + No Yes N/A Off Vulnerable
235 + No Yes N/A Full Mitigated
236 + ============ ===== ============= ============ =================
238 + This only covers the host to guest transition, i.e. prevents leakage from
239 + host to guest, but does not protect the guest internally. Guests need to
240 + have their own protections.
244 +XEON PHI specific considerations
245 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
247 + The XEON PHI processor family is affected by MSBDS which can be exploited
248 + cross Hyper-Threads when entering idle states. Some XEON PHI variants allow
249 + to use MWAIT in user space (Ring 3) which opens an potential attack vector
250 + for malicious user space. The exposure can be disabled on the kernel
251 + command line with the 'ring3mwait=disable' command line option.
253 + XEON PHI is not affected by the other MDS variants and MSBDS is mitigated
254 + before the CPU enters a idle state. As XEON PHI is not affected by L1TF
255 + either disabling SMT is not required for full protection.
257 +.. _mds_smt_control:
262 + All MDS variants except MSBDS can be attacked cross Hyper-Threads. That
263 + means on CPUs which are affected by MFBDS or MLPDS it is necessary to
264 + disable SMT for full protection. These are most of the affected CPUs; the
265 + exception is XEON PHI, see :ref:`xeon_phi`.
267 + Disabling SMT can have a significant performance impact, but the impact
268 + depends on the type of workloads.
270 + See the relevant chapter in the L1TF mitigation documentation for details:
271 + :ref:`Documentation/hw-vuln/l1tf.rst <smt_control>`.
274 +.. _mds_mitigation_control_command_line:
276 +Mitigation control on the kernel command line
277 +---------------------------------------------
279 +The kernel command line allows to control the MDS mitigations at boot
280 +time with the option "mds=". The valid arguments for this option are:
282 + ============ =============================================================
283 + full If the CPU is vulnerable, enable all available mitigations
284 + for the MDS vulnerability, CPU buffer clearing on exit to
285 + userspace and when entering a VM. Idle transitions are
286 + protected as well if SMT is enabled.
288 + It does not automatically disable SMT.
290 + off Disables MDS mitigations completely.
292 + ============ =============================================================
294 +Not specifying this option is equivalent to "mds=full".
297 +Mitigation selection guide
298 +--------------------------
300 +1. Trusted userspace
301 +^^^^^^^^^^^^^^^^^^^^
303 + If all userspace applications are from a trusted source and do not
304 + execute untrusted code which is supplied externally, then the mitigation
308 +2. Virtualization with trusted guests
309 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
311 + The same considerations as above versus trusted user space apply.
313 +3. Virtualization with untrusted guests
314 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
316 + The protection depends on the state of the L1TF mitigations.
317 + See :ref:`virt_mechanism`.
319 + If the MDS mitigation is enabled and SMT is disabled, guest to host and
320 + guest to guest attacks are prevented.
322 +.. _mds_default_mitigations:
327 + The kernel default mitigations for vulnerable processors are:
329 + - Enable CPU buffer clearing
331 + The kernel does not by default enforce the disabling of SMT, which leaves
332 + SMT systems vulnerable when running untrusted code. The same rationale as
334 + See :ref:`Documentation/hw-vuln//l1tf.rst <default_mitigations>`.
335 --- a/Documentation/kernel-parameters.txt
336 +++ b/Documentation/kernel-parameters.txt
337 @@ -2057,6 +2057,8 @@ bytes respectively. Such letter suffixes
338 Not specifying this option is equivalent to
341 + For details see: Documentation/hw-vuln/mds.rst
343 mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory
344 Amount of memory to be used when the kernel is not able
345 to see the whole system memory or for test.