releases/4.9.176/0063-Documentation-Add-MDS-vulnerability-documentation.patch

   1 From b3b7f61a91c8c23238897904054f4afa7f1f7a37 Mon Sep 17 00:00:00 2001
   2 From: Thomas Gleixner <tglx@linutronix.de>
   3 Date: Tue, 19 Feb 2019 00:02:31 +0100
   4 Subject: [PATCH 63/76] Documentation: Add MDS vulnerability documentation
   5
   6 commit 5999bbe7a6ea3c62029532ec84dc06003a1fa258 upstream.
   7
   8 Add the initial MDS vulnerability documentation.
   9
  10 Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  11 Reviewed-by: Jon Masters <jcm@redhat.com>
  12 [bwh: Backported to 4.9: adjust filenames]
  13 Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  14 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  15 ---
  16  .../ABI/testing/sysfs-devices-system-cpu      |   3 +-
  17  Documentation/hw-vuln/index.rst               |   1 +
  18  Documentation/hw-vuln/l1tf.rst                |   1 +
  19  Documentation/hw-vuln/mds.rst                 | 307 ++++++++++++++++++
  20  Documentation/kernel-parameters.txt           |   2 +
  21  5 files changed, 312 insertions(+), 2 deletions(-)
  22  create mode 100644 Documentation/hw-vuln/mds.rst
  23
  24 diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
  25 index 1f5d22bbf766..cadb7a9a5218 100644
  26 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
  27 +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
  28 @@ -370,8 +370,7 @@ Description:        Information about CPU vulnerabilities
  29                 "Vulnerable"      CPU is affected and no mitigation in effect
  30                 "Mitigation: $M"  CPU is affected and mitigation $M is in effect
  31
  32 -               Details about the l1tf file can be found in
  33 -               Documentation/hw-vuln/l1tf.rst
  34 +               See also: Documentation/hw-vuln/index.rst
  35
  36  What:          /sys/devices/system/cpu/smt
  37                 /sys/devices/system/cpu/smt/active
  38 diff --git a/Documentation/hw-vuln/index.rst b/Documentation/hw-vuln/index.rst
  39 index 8ce2009f1981..ffc064c1ec68 100644
  40 --- a/Documentation/hw-vuln/index.rst
  41 +++ b/Documentation/hw-vuln/index.rst
  42 @@ -10,3 +10,4 @@ are configurable at compile, boot or run time.
  43     :maxdepth: 1
  44
  45     l1tf
  46 +   mds
  47 diff --git a/Documentation/hw-vuln/l1tf.rst b/Documentation/hw-vuln/l1tf.rst
  48 index 9af977384168..31653a9f0e1b 100644
  49 --- a/Documentation/hw-vuln/l1tf.rst
  50 +++ b/Documentation/hw-vuln/l1tf.rst
  51 @@ -445,6 +445,7 @@ The default is 'cond'. If 'l1tf=full,force' is given on the kernel command
  52  line, then 'always' is enforced and the kvm-intel.vmentry_l1d_flush
  53  module parameter is ignored and writes to the sysfs file are rejected.
  54
  55 +.. _mitigation_selection:
  56
  57  Mitigation selection guide
  58  --------------------------
  59 diff --git a/Documentation/hw-vuln/mds.rst b/Documentation/hw-vuln/mds.rst
  60 new file mode 100644
  61 index 000000000000..ff6bfdb97eee
  62 --- /dev/null
  63 +++ b/Documentation/hw-vuln/mds.rst
  64 @@ -0,0 +1,307 @@
  65 +MDS - Microarchitectural Data Sampling
  66 +======================================
  67 +
  68 +Microarchitectural Data Sampling is a hardware vulnerability which allows
  69 +unprivileged speculative access to data which is available in various CPU
  70 +internal buffers.
  71 +
  72 +Affected processors
  73 +-------------------
  74 +
  75 +This vulnerability affects a wide range of Intel processors. The
  76 +vulnerability is not present on:
  77 +
  78 +   - Processors from AMD, Centaur and other non Intel vendors
  79 +
  80 +   - Older processor models, where the CPU family is < 6
  81 +
  82 +   - Some Atoms (Bonnell, Saltwell, Goldmont, GoldmontPlus)
  83 +
  84 +   - Intel processors which have the ARCH_CAP_MDS_NO bit set in the
  85 +     IA32_ARCH_CAPABILITIES MSR.
  86 +
  87 +Whether a processor is affected or not can be read out from the MDS
  88 +vulnerability file in sysfs. See :ref:`mds_sys_info`.
  89 +
  90 +Not all processors are affected by all variants of MDS, but the mitigation
  91 +is identical for all of them so the kernel treats them as a single
  92 +vulnerability.
  93 +
  94 +Related CVEs
  95 +------------
  96 +
  97 +The following CVE entries are related to the MDS vulnerability:
  98 +
  99 +   ==============  =====  ==============================================
 100 +   CVE-2018-12126  MSBDS  Microarchitectural Store Buffer Data Sampling
 101 +   CVE-2018-12130  MFBDS  Microarchitectural Fill Buffer Data Sampling
 102 +   CVE-2018-12127  MLPDS  Microarchitectural Load Port Data Sampling
 103 +   ==============  =====  ==============================================
 104 +
 105 +Problem
 106 +-------
 107 +
 108 +When performing store, load, L1 refill operations, processors write data
 109 +into temporary microarchitectural structures (buffers). The data in the
 110 +buffer can be forwarded to load operations as an optimization.
 111 +
 112 +Under certain conditions, usually a fault/assist caused by a load
 113 +operation, data unrelated to the load memory address can be speculatively
 114 +forwarded from the buffers. Because the load operation causes a fault or
 115 +assist and its result will be discarded, the forwarded data will not cause
 116 +incorrect program execution or state changes. But a malicious operation
 117 +may be able to forward this speculative data to a disclosure gadget which
 118 +allows in turn to infer the value via a cache side channel attack.
 119 +
 120 +Because the buffers are potentially shared between Hyper-Threads cross
 121 +Hyper-Thread attacks are possible.
 122 +
 123 +Deeper technical information is available in the MDS specific x86
 124 +architecture section: :ref:`Documentation/x86/mds.rst <mds>`.
 125 +
 126 +
 127 +Attack scenarios
 128 +----------------
 129 +
 130 +Attacks against the MDS vulnerabilities can be mounted from malicious non
 131 +priviledged user space applications running on hosts or guest. Malicious
 132 +guest OSes can obviously mount attacks as well.
 133 +
 134 +Contrary to other speculation based vulnerabilities the MDS vulnerability
 135 +does not allow the attacker to control the memory target address. As a
 136 +consequence the attacks are purely sampling based, but as demonstrated with
 137 +the TLBleed attack samples can be postprocessed successfully.
 138 +
 139 +Web-Browsers
 140 +^^^^^^^^^^^^
 141 +
 142 +  It's unclear whether attacks through Web-Browsers are possible at
 143 +  all. The exploitation through Java-Script is considered very unlikely,
 144 +  but other widely used web technologies like Webassembly could possibly be
 145 +  abused.
 146 +
 147 +
 148 +.. _mds_sys_info:
 149 +
 150 +MDS system information
 151 +-----------------------
 152 +
 153 +The Linux kernel provides a sysfs interface to enumerate the current MDS
 154 +status of the system: whether the system is vulnerable, and which
 155 +mitigations are active. The relevant sysfs file is:
 156 +
 157 +/sys/devices/system/cpu/vulnerabilities/mds
 158 +
 159 +The possible values in this file are:
 160 +
 161 +  =========================================   =================================
 162 +  'Not affected'                               The processor is not vulnerable
 163 +
 164 +  'Vulnerable'                                 The processor is vulnerable,
 165 +                                               but no mitigation enabled
 166 +
 167 +  'Vulnerable: Clear CPU buffers attempted'    The processor is vulnerable but
 168 +                                               microcode is not updated.
 169 +                                               The mitigation is enabled on a
 170 +                                               best effort basis.
 171 +                                               See :ref:`vmwerv`
 172 +
 173 +  'Mitigation: CPU buffer clear'               The processor is vulnerable and the
 174 +                                               CPU buffer clearing mitigation is
 175 +                                               enabled.
 176 +  =========================================   =================================
 177 +
 178 +If the processor is vulnerable then the following information is appended
 179 +to the above information:
 180 +
 181 +    ========================  ============================================
 182 +    'SMT vulnerable'          SMT is enabled
 183 +    'SMT mitigated'           SMT is enabled and mitigated
 184 +    'SMT disabled'            SMT is disabled
 185 +    'SMT Host state unknown'  Kernel runs in a VM, Host SMT state unknown
 186 +    ========================  ============================================
 187 +
 188 +.. _vmwerv:
 189 +
 190 +Best effort mitigation mode
 191 +^^^^^^^^^^^^^^^^^^^^^^^^^^^
 192 +
 193 +  If the processor is vulnerable, but the availability of the microcode based
 194 +  mitigation mechanism is not advertised via CPUID the kernel selects a best
 195 +  effort mitigation mode.  This mode invokes the mitigation instructions
 196 +  without a guarantee that they clear the CPU buffers.
 197 +
 198 +  This is done to address virtualization scenarios where the host has the
 199 +  microcode update applied, but the hypervisor is not yet updated to expose
 200 +  the CPUID to the guest. If the host has updated microcode the protection
 201 +  takes effect otherwise a few cpu cycles are wasted pointlessly.
 202 +
 203 +  The state in the mds sysfs file reflects this situation accordingly.
 204 +
 205 +
 206 +Mitigation mechanism
 207 +-------------------------
 208 +
 209 +The kernel detects the affected CPUs and the presence of the microcode
 210 +which is required.
 211 +
 212 +If a CPU is affected and the microcode is available, then the kernel
 213 +enables the mitigation by default. The mitigation can be controlled at boot
 214 +time via a kernel command line option. See
 215 +:ref:`mds_mitigation_control_command_line`.
 216 +
 217 +.. _cpu_buffer_clear:
 218 +
 219 +CPU buffer clearing
 220 +^^^^^^^^^^^^^^^^^^^
 221 +
 222 +  The mitigation for MDS clears the affected CPU buffers on return to user
 223 +  space and when entering a guest.
 224 +
 225 +  If SMT is enabled it also clears the buffers on idle entry when the CPU
 226 +  is only affected by MSBDS and not any other MDS variant, because the
 227 +  other variants cannot be protected against cross Hyper-Thread attacks.
 228 +
 229 +  For CPUs which are only affected by MSBDS the user space, guest and idle
 230 +  transition mitigations are sufficient and SMT is not affected.
 231 +
 232 +.. _virt_mechanism:
 233 +
 234 +Virtualization mitigation
 235 +^^^^^^^^^^^^^^^^^^^^^^^^^
 236 +
 237 +  The protection for host to guest transition depends on the L1TF
 238 +  vulnerability of the CPU:
 239 +
 240 +  - CPU is affected by L1TF:
 241 +
 242 +    If the L1D flush mitigation is enabled and up to date microcode is
 243 +    available, the L1D flush mitigation is automatically protecting the
 244 +    guest transition.
 245 +
 246 +    If the L1D flush mitigation is disabled then the MDS mitigation is
 247 +    invoked explicit when the host MDS mitigation is enabled.
 248 +
 249 +    For details on L1TF and virtualization see:
 250 +    :ref:`Documentation/hw-vuln//l1tf.rst <mitigation_control_kvm>`.
 251 +
 252 +  - CPU is not affected by L1TF:
 253 +
 254 +    CPU buffers are flushed before entering the guest when the host MDS
 255 +    mitigation is enabled.
 256 +
 257 +  The resulting MDS protection matrix for the host to guest transition:
 258 +
 259 +  ============ ===== ============= ============ =================
 260 +   L1TF         MDS   VMX-L1FLUSH   Host MDS     MDS-State
 261 +
 262 +   Don't care   No    Don't care    N/A          Not affected
 263 +
 264 +   Yes          Yes   Disabled      Off          Vulnerable
 265 +
 266 +   Yes          Yes   Disabled      Full         Mitigated
 267 +
 268 +   Yes          Yes   Enabled       Don't care   Mitigated
 269 +
 270 +   No           Yes   N/A           Off          Vulnerable
 271 +
 272 +   No           Yes   N/A           Full         Mitigated
 273 +  ============ ===== ============= ============ =================
 274 +
 275 +  This only covers the host to guest transition, i.e. prevents leakage from
 276 +  host to guest, but does not protect the guest internally. Guests need to
 277 +  have their own protections.
 278 +
 279 +.. _xeon_phi:
 280 +
 281 +XEON PHI specific considerations
 282 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 283 +
 284 +  The XEON PHI processor family is affected by MSBDS which can be exploited
 285 +  cross Hyper-Threads when entering idle states. Some XEON PHI variants allow
 286 +  to use MWAIT in user space (Ring 3) which opens an potential attack vector
 287 +  for malicious user space. The exposure can be disabled on the kernel
 288 +  command line with the 'ring3mwait=disable' command line option.
 289 +
 290 +  XEON PHI is not affected by the other MDS variants and MSBDS is mitigated
 291 +  before the CPU enters a idle state. As XEON PHI is not affected by L1TF
 292 +  either disabling SMT is not required for full protection.
 293 +
 294 +.. _mds_smt_control:
 295 +
 296 +SMT control
 297 +^^^^^^^^^^^
 298 +
 299 +  All MDS variants except MSBDS can be attacked cross Hyper-Threads. That
 300 +  means on CPUs which are affected by MFBDS or MLPDS it is necessary to
 301 +  disable SMT for full protection. These are most of the affected CPUs; the
 302 +  exception is XEON PHI, see :ref:`xeon_phi`.
 303 +
 304 +  Disabling SMT can have a significant performance impact, but the impact
 305 +  depends on the type of workloads.
 306 +
 307 +  See the relevant chapter in the L1TF mitigation documentation for details:
 308 +  :ref:`Documentation/hw-vuln/l1tf.rst <smt_control>`.
 309 +
 310 +
 311 +.. _mds_mitigation_control_command_line:
 312 +
 313 +Mitigation control on the kernel command line
 314 +---------------------------------------------
 315 +
 316 +The kernel command line allows to control the MDS mitigations at boot
 317 +time with the option "mds=". The valid arguments for this option are:
 318 +
 319 +  ============  =============================================================
 320 +  full         If the CPU is vulnerable, enable all available mitigations
 321 +               for the MDS vulnerability, CPU buffer clearing on exit to
 322 +               userspace and when entering a VM. Idle transitions are
 323 +               protected as well if SMT is enabled.
 324 +
 325 +               It does not automatically disable SMT.
 326 +
 327 +  off          Disables MDS mitigations completely.
 328 +
 329 +  ============  =============================================================
 330 +
 331 +Not specifying this option is equivalent to "mds=full".
 332 +
 333 +
 334 +Mitigation selection guide
 335 +--------------------------
 336 +
 337 +1. Trusted userspace
 338 +^^^^^^^^^^^^^^^^^^^^
 339 +
 340 +   If all userspace applications are from a trusted source and do not
 341 +   execute untrusted code which is supplied externally, then the mitigation
 342 +   can be disabled.
 343 +
 344 +
 345 +2. Virtualization with trusted guests
 346 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 347 +
 348 +   The same considerations as above versus trusted user space apply.
 349 +
 350 +3. Virtualization with untrusted guests
 351 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 352 +
 353 +   The protection depends on the state of the L1TF mitigations.
 354 +   See :ref:`virt_mechanism`.
 355 +
 356 +   If the MDS mitigation is enabled and SMT is disabled, guest to host and
 357 +   guest to guest attacks are prevented.
 358 +
 359 +.. _mds_default_mitigations:
 360 +
 361 +Default mitigations
 362 +-------------------
 363 +
 364 +  The kernel default mitigations for vulnerable processors are:
 365 +
 366 +  - Enable CPU buffer clearing
 367 +
 368 +  The kernel does not by default enforce the disabling of SMT, which leaves
 369 +  SMT systems vulnerable when running untrusted code. The same rationale as
 370 +  for L1TF applies.
 371 +  See :ref:`Documentation/hw-vuln//l1tf.rst <default_mitigations>`.
 372 diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
 373 index 12c33e542163..7164790b82c0 100644
 374 --- a/Documentation/kernel-parameters.txt
 375 +++ b/Documentation/kernel-parameters.txt
 376 @@ -2347,6 +2347,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 377                         Not specifying this option is equivalent to
 378                         mds=full.
 379
 380 +                       For details see: Documentation/hw-vuln/mds.rst
 381 +
 382         mem=nn[KMG]     [KNL,BOOT] Force usage of a specific amount of memory
 383                         Amount of memory to be used when the kernel is not able
 384                         to see the whole system memory or for test.
 385 --
 386 2.21.0
 387