Documentation/admin-guide/hw-vuln/mds.rst

   1 MDS - Microarchitectural Data Sampling
   2 ======================================
   3
   4 Microarchitectural Data Sampling is a hardware vulnerability which allows
   5 unprivileged speculative access to data which is available in various CPU
   6 internal buffers.
   7
   8 Affected processors
   9 -------------------
  10
  11 This vulnerability affects a wide range of Intel processors. The
  12 vulnerability is not present on:
  13
  14    - Processors from AMD, Centaur and other non Intel vendors
  15
  16    - Older processor models, where the CPU family is < 6
  17
  18    - Some Atoms (Bonnell, Saltwell, Goldmont, GoldmontPlus)
  19
  20    - Intel processors which have the ARCH_CAP_MDS_NO bit set in the
  21      IA32_ARCH_CAPABILITIES MSR.
  22
  23 Whether a processor is affected or not can be read out from the MDS
  24 vulnerability file in sysfs. See :ref:`mds_sys_info`.
  25
  26 Not all processors are affected by all variants of MDS, but the mitigation
  27 is identical for all of them so the kernel treats them as a single
  28 vulnerability.
  29
  30 Related CVEs
  31 ------------
  32
  33 The following CVE entries are related to the MDS vulnerability:
  34
  35    ==============  =====  ==============================================
  36    CVE-2018-12126  MSBDS  Microarchitectural Store Buffer Data Sampling
  37    CVE-2018-12130  MFBDS  Microarchitectural Fill Buffer Data Sampling
  38    CVE-2018-12127  MLPDS  Microarchitectural Load Port Data Sampling
  39    ==============  =====  ==============================================
  40
  41 Problem
  42 -------
  43
  44 When performing store, load, L1 refill operations, processors write data
  45 into temporary microarchitectural structures (buffers). The data in the
  46 buffer can be forwarded to load operations as an optimization.
  47
  48 Under certain conditions, usually a fault/assist caused by a load
  49 operation, data unrelated to the load memory address can be speculatively
  50 forwarded from the buffers. Because the load operation causes a fault or
  51 assist and its result will be discarded, the forwarded data will not cause
  52 incorrect program execution or state changes. But a malicious operation
  53 may be able to forward this speculative data to a disclosure gadget which
  54 allows in turn to infer the value via a cache side channel attack.
  55
  56 Because the buffers are potentially shared between Hyper-Threads cross
  57 Hyper-Thread attacks are possible.
  58
  59 Deeper technical information is available in the MDS specific x86
  60 architecture section: :ref:`Documentation/x86/mds.rst <mds>`.
  61
  62
  63 Attack scenarios
  64 ----------------
  65
  66 Attacks against the MDS vulnerabilities can be mounted from malicious non
  67 priviledged user space applications running on hosts or guest. Malicious
  68 guest OSes can obviously mount attacks as well.
  69
  70 Contrary to other speculation based vulnerabilities the MDS vulnerability
  71 does not allow the attacker to control the memory target address. As a
  72 consequence the attacks are purely sampling based, but as demonstrated with
  73 the TLBleed attack samples can be postprocessed successfully.
  74
  75 Web-Browsers
  76 ^^^^^^^^^^^^
  77
  78   It's unclear whether attacks through Web-Browsers are possible at
  79   all. The exploitation through Java-Script is considered very unlikely,
  80   but other widely used web technologies like Webassembly could possibly be
  81   abused.
  82
  83
  84 .. _mds_sys_info:
  85
  86 MDS system information
  87 -----------------------
  88
  89 The Linux kernel provides a sysfs interface to enumerate the current MDS
  90 status of the system: whether the system is vulnerable, and which
  91 mitigations are active. The relevant sysfs file is:
  92
  93 /sys/devices/system/cpu/vulnerabilities/mds
  94
  95 The possible values in this file are:
  96
  97   =========================================   =================================
  98   'Not affected'                                The processor is not vulnerable
  99
 100   'Vulnerable'                                  The processor is vulnerable,
 101                                                 but no mitigation enabled
 102
 103   'Vulnerable: Clear CPU buffers attempted'     The processor is vulnerable but
 104                                                 microcode is not updated.
 105                                                 The mitigation is enabled on a
 106                                                 best effort basis.
 107                                                 See :ref:`vmwerv`
 108
 109   'Mitigation: CPU buffer clear'                The processor is vulnerable and the
 110                                                 CPU buffer clearing mitigation is
 111                                                 enabled.
 112   =========================================   =================================
 113
 114 If the processor is vulnerable then the following information is appended
 115 to the above information:
 116
 117     ========================  ============================================
 118     'SMT vulnerable'          SMT is enabled
 119     'SMT mitigated'           SMT is enabled and mitigated
 120     'SMT disabled'            SMT is disabled
 121     'SMT Host state unknown'  Kernel runs in a VM, Host SMT state unknown
 122     ========================  ============================================
 123
 124 .. _vmwerv:
 125
 126 Best effort mitigation mode
 127 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 128
 129   If the processor is vulnerable, but the availability of the microcode based
 130   mitigation mechanism is not advertised via CPUID the kernel selects a best
 131   effort mitigation mode.  This mode invokes the mitigation instructions
 132   without a guarantee that they clear the CPU buffers.
 133
 134   This is done to address virtualization scenarios where the host has the
 135   microcode update applied, but the hypervisor is not yet updated to expose
 136   the CPUID to the guest. If the host has updated microcode the protection
 137   takes effect otherwise a few cpu cycles are wasted pointlessly.
 138
 139   The state in the mds sysfs file reflects this situation accordingly.
 140
 141
 142 Mitigation mechanism
 143 -------------------------
 144
 145 The kernel detects the affected CPUs and the presence of the microcode
 146 which is required.
 147
 148 If a CPU is affected and the microcode is available, then the kernel
 149 enables the mitigation by default. The mitigation can be controlled at boot
 150 time via a kernel command line option. See
 151 :ref:`mds_mitigation_control_command_line`.
 152
 153 .. _cpu_buffer_clear:
 154
 155 CPU buffer clearing
 156 ^^^^^^^^^^^^^^^^^^^
 157
 158   The mitigation for MDS clears the affected CPU buffers on return to user
 159   space and when entering a guest.
 160
 161   If SMT is enabled it also clears the buffers on idle entry when the CPU
 162   is only affected by MSBDS and not any other MDS variant, because the
 163   other variants cannot be protected against cross Hyper-Thread attacks.
 164
 165   For CPUs which are only affected by MSBDS the user space, guest and idle
 166   transition mitigations are sufficient and SMT is not affected.
 167
 168 .. _virt_mechanism:
 169
 170 Virtualization mitigation
 171 ^^^^^^^^^^^^^^^^^^^^^^^^^
 172
 173   The protection for host to guest transition depends on the L1TF
 174   vulnerability of the CPU:
 175
 176   - CPU is affected by L1TF:
 177
 178     If the L1D flush mitigation is enabled and up to date microcode is
 179     available, the L1D flush mitigation is automatically protecting the
 180     guest transition.
 181
 182     If the L1D flush mitigation is disabled then the MDS mitigation is
 183     invoked explicit when the host MDS mitigation is enabled.
 184
 185     For details on L1TF and virtualization see:
 186     :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <mitigation_control_kvm>`.
 187
 188   - CPU is not affected by L1TF:
 189
 190     CPU buffers are flushed before entering the guest when the host MDS
 191     mitigation is enabled.
 192
 193   The resulting MDS protection matrix for the host to guest transition:
 194
 195   ============ ===== ============= ============ =================
 196    L1TF         MDS   VMX-L1FLUSH   Host MDS     MDS-State
 197
 198    Don't care   No    Don't care    N/A          Not affected
 199
 200    Yes          Yes   Disabled      Off          Vulnerable
 201
 202    Yes          Yes   Disabled      Full         Mitigated
 203
 204    Yes          Yes   Enabled       Don't care   Mitigated
 205
 206    No           Yes   N/A           Off          Vulnerable
 207
 208    No           Yes   N/A           Full         Mitigated
 209   ============ ===== ============= ============ =================
 210
 211   This only covers the host to guest transition, i.e. prevents leakage from
 212   host to guest, but does not protect the guest internally. Guests need to
 213   have their own protections.
 214
 215 .. _xeon_phi:
 216
 217 XEON PHI specific considerations
 218 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 219
 220   The XEON PHI processor family is affected by MSBDS which can be exploited
 221   cross Hyper-Threads when entering idle states. Some XEON PHI variants allow
 222   to use MWAIT in user space (Ring 3) which opens an potential attack vector
 223   for malicious user space. The exposure can be disabled on the kernel
 224   command line with the 'ring3mwait=disable' command line option.
 225
 226   XEON PHI is not affected by the other MDS variants and MSBDS is mitigated
 227   before the CPU enters a idle state. As XEON PHI is not affected by L1TF
 228   either disabling SMT is not required for full protection.
 229
 230 .. _mds_smt_control:
 231
 232 SMT control
 233 ^^^^^^^^^^^
 234
 235   All MDS variants except MSBDS can be attacked cross Hyper-Threads. That
 236   means on CPUs which are affected by MFBDS or MLPDS it is necessary to
 237   disable SMT for full protection. These are most of the affected CPUs; the
 238   exception is XEON PHI, see :ref:`xeon_phi`.
 239
 240   Disabling SMT can have a significant performance impact, but the impact
 241   depends on the type of workloads.
 242
 243   See the relevant chapter in the L1TF mitigation documentation for details:
 244   :ref:`Documentation/admin-guide/hw-vuln/l1tf.rst <smt_control>`.
 245
 246
 247 .. _mds_mitigation_control_command_line:
 248
 249 Mitigation control on the kernel command line
 250 ---------------------------------------------
 251
 252 The kernel command line allows to control the MDS mitigations at boot
 253 time with the option "mds=". The valid arguments for this option are:
 254
 255   ============  =============================================================
 256   full          If the CPU is vulnerable, enable all available mitigations
 257                 for the MDS vulnerability, CPU buffer clearing on exit to
 258                 userspace and when entering a VM. Idle transitions are
 259                 protected as well if SMT is enabled.
 260
 261                 It does not automatically disable SMT.
 262
 263   full,nosmt    The same as mds=full, with SMT disabled on vulnerable
 264                 CPUs.  This is the complete mitigation.
 265
 266   off           Disables MDS mitigations completely.
 267
 268   ============  =============================================================
 269
 270 Not specifying this option is equivalent to "mds=full".
 271
 272
 273 Mitigation selection guide
 274 --------------------------
 275
 276 1. Trusted userspace
 277 ^^^^^^^^^^^^^^^^^^^^
 278
 279    If all userspace applications are from a trusted source and do not
 280    execute untrusted code which is supplied externally, then the mitigation
 281    can be disabled.
 282
 283
 284 2. Virtualization with trusted guests
 285 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 286
 287    The same considerations as above versus trusted user space apply.
 288
 289 3. Virtualization with untrusted guests
 290 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 291
 292    The protection depends on the state of the L1TF mitigations.
 293    See :ref:`virt_mechanism`.
 294
 295    If the MDS mitigation is enabled and SMT is disabled, guest to host and
 296    guest to guest attacks are prevented.
 297
 298 .. _mds_default_mitigations:
 299
 300 Default mitigations
 301 -------------------
 302
 303   The kernel default mitigations for vulnerable processors are:
 304
 305   - Enable CPU buffer clearing
 306
 307   The kernel does not by default enforce the disabling of SMT, which leaves
 308   SMT systems vulnerable when running untrusted code. The same rationale as
 309   for L1TF applies.
 310   See :ref:`Documentation/admin-guide/hw-vuln//l1tf.rst <default_mitigations>`.