releases/5.0.16/0014-Documentation-Add-MDS-vulnerability-documentation.patch

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