queue-4.9/0055-x86-speculation-mds-Add-mds_clear_cpu_buffers.patch

   1 From e502c7a9b3591cbaf7f3a136f5e46f4e2499ea22 Mon Sep 17 00:00:00 2001
   2 From: Thomas Gleixner <tglx@linutronix.de>
   3 Date: Mon, 18 Feb 2019 23:13:06 +0100
   4 Subject: [PATCH 55/76] x86/speculation/mds: Add mds_clear_cpu_buffers()
   5
   6 commit 6a9e529272517755904b7afa639f6db59ddb793e upstream.
   7
   8 The Microarchitectural Data Sampling (MDS) vulernabilities are mitigated by
   9 clearing the affected CPU buffers. The mechanism for clearing the buffers
  10 uses the unused and obsolete VERW instruction in combination with a
  11 microcode update which triggers a CPU buffer clear when VERW is executed.
  12
  13 Provide a inline function with the assembly magic. The argument of the VERW
  14 instruction must be a memory operand as documented:
  15
  16   "MD_CLEAR enumerates that the memory-operand variant of VERW (for
  17    example, VERW m16) has been extended to also overwrite buffers affected
  18    by MDS. This buffer overwriting functionality is not guaranteed for the
  19    register operand variant of VERW."
  20
  21 Documentation also recommends to use a writable data segment selector:
  22
  23   "The buffer overwriting occurs regardless of the result of the VERW
  24    permission check, as well as when the selector is null or causes a
  25    descriptor load segment violation. However, for lowest latency we
  26    recommend using a selector that indicates a valid writable data
  27    segment."
  28
  29 Add x86 specific documentation about MDS and the internal workings of the
  30 mitigation.
  31
  32 Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
  33 Reviewed-by: Borislav Petkov <bp@suse.de>
  34 Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  35 Reviewed-by: Frederic Weisbecker <frederic@kernel.org>
  36 Reviewed-by: Jon Masters <jcm@redhat.com>
  37 Tested-by: Jon Masters <jcm@redhat.com>
  38 [bwh: Backported to 4.9: add the "Architecture-specific documentation"
  39  section to the index]
  40 Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
  41 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  42 ---
  43  Documentation/index.rst              | 11 ++++
  44  Documentation/x86/conf.py            | 10 +++
  45  Documentation/x86/index.rst          |  8 +++
  46  Documentation/x86/mds.rst            | 99 ++++++++++++++++++++++++++++
  47  arch/x86/include/asm/nospec-branch.h | 25 +++++++
  48  5 files changed, 153 insertions(+)
  49  create mode 100644 Documentation/x86/conf.py
  50  create mode 100644 Documentation/x86/index.rst
  51  create mode 100644 Documentation/x86/mds.rst
  52
  53 diff --git a/Documentation/index.rst b/Documentation/index.rst
  54 index 213399aac757..18b2484d19ef 100644
  55 --- a/Documentation/index.rst
  56 +++ b/Documentation/index.rst
  57 @@ -20,6 +20,17 @@ Contents:
  58     gpu/index
  59     80211/index
  60
  61 +Architecture-specific documentation
  62 +-----------------------------------
  63 +
  64 +These books provide programming details about architecture-specific
  65 +implementation.
  66 +
  67 +.. toctree::
  68 +   :maxdepth: 2
  69 +
  70 +   x86/index
  71 +
  72  Indices and tables
  73  ==================
  74
  75 diff --git a/Documentation/x86/conf.py b/Documentation/x86/conf.py
  76 new file mode 100644
  77 index 000000000000..33c5c3142e20
  78 --- /dev/null
  79 +++ b/Documentation/x86/conf.py
  80 @@ -0,0 +1,10 @@
  81 +# -*- coding: utf-8; mode: python -*-
  82 +
  83 +project = "X86 architecture specific documentation"
  84 +
  85 +tags.add("subproject")
  86 +
  87 +latex_documents = [
  88 +    ('index', 'x86.tex', project,
  89 +     'The kernel development community', 'manual'),
  90 +]
  91 diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
  92 new file mode 100644
  93 index 000000000000..ef389dcf1b1d
  94 --- /dev/null
  95 +++ b/Documentation/x86/index.rst
  96 @@ -0,0 +1,8 @@
  97 +==========================
  98 +x86 architecture specifics
  99 +==========================
 100 +
 101 +.. toctree::
 102 +   :maxdepth: 1
 103 +
 104 +   mds
 105 diff --git a/Documentation/x86/mds.rst b/Documentation/x86/mds.rst
 106 new file mode 100644
 107 index 000000000000..1096738d50f2
 108 --- /dev/null
 109 +++ b/Documentation/x86/mds.rst
 110 @@ -0,0 +1,99 @@
 111 +Microarchitectural Data Sampling (MDS) mitigation
 112 +=================================================
 113 +
 114 +.. _mds:
 115 +
 116 +Overview
 117 +--------
 118 +
 119 +Microarchitectural Data Sampling (MDS) is a family of side channel attacks
 120 +on internal buffers in Intel CPUs. The variants are:
 121 +
 122 + - Microarchitectural Store Buffer Data Sampling (MSBDS) (CVE-2018-12126)
 123 + - Microarchitectural Fill Buffer Data Sampling (MFBDS) (CVE-2018-12130)
 124 + - Microarchitectural Load Port Data Sampling (MLPDS) (CVE-2018-12127)
 125 +
 126 +MSBDS leaks Store Buffer Entries which can be speculatively forwarded to a
 127 +dependent load (store-to-load forwarding) as an optimization. The forward
 128 +can also happen to a faulting or assisting load operation for a different
 129 +memory address, which can be exploited under certain conditions. Store
 130 +buffers are partitioned between Hyper-Threads so cross thread forwarding is
 131 +not possible. But if a thread enters or exits a sleep state the store
 132 +buffer is repartitioned which can expose data from one thread to the other.
 133 +
 134 +MFBDS leaks Fill Buffer Entries. Fill buffers are used internally to manage
 135 +L1 miss situations and to hold data which is returned or sent in response
 136 +to a memory or I/O operation. Fill buffers can forward data to a load
 137 +operation and also write data to the cache. When the fill buffer is
 138 +deallocated it can retain the stale data of the preceding operations which
 139 +can then be forwarded to a faulting or assisting load operation, which can
 140 +be exploited under certain conditions. Fill buffers are shared between
 141 +Hyper-Threads so cross thread leakage is possible.
 142 +
 143 +MLPDS leaks Load Port Data. Load ports are used to perform load operations
 144 +from memory or I/O. The received data is then forwarded to the register
 145 +file or a subsequent operation. In some implementations the Load Port can
 146 +contain stale data from a previous operation which can be forwarded to
 147 +faulting or assisting loads under certain conditions, which again can be
 148 +exploited eventually. Load ports are shared between Hyper-Threads so cross
 149 +thread leakage is possible.
 150 +
 151 +
 152 +Exposure assumptions
 153 +--------------------
 154 +
 155 +It is assumed that attack code resides in user space or in a guest with one
 156 +exception. The rationale behind this assumption is that the code construct
 157 +needed for exploiting MDS requires:
 158 +
 159 + - to control the load to trigger a fault or assist
 160 +
 161 + - to have a disclosure gadget which exposes the speculatively accessed
 162 +   data for consumption through a side channel.
 163 +
 164 + - to control the pointer through which the disclosure gadget exposes the
 165 +   data
 166 +
 167 +The existence of such a construct in the kernel cannot be excluded with
 168 +100% certainty, but the complexity involved makes it extremly unlikely.
 169 +
 170 +There is one exception, which is untrusted BPF. The functionality of
 171 +untrusted BPF is limited, but it needs to be thoroughly investigated
 172 +whether it can be used to create such a construct.
 173 +
 174 +
 175 +Mitigation strategy
 176 +-------------------
 177 +
 178 +All variants have the same mitigation strategy at least for the single CPU
 179 +thread case (SMT off): Force the CPU to clear the affected buffers.
 180 +
 181 +This is achieved by using the otherwise unused and obsolete VERW
 182 +instruction in combination with a microcode update. The microcode clears
 183 +the affected CPU buffers when the VERW instruction is executed.
 184 +
 185 +For virtualization there are two ways to achieve CPU buffer
 186 +clearing. Either the modified VERW instruction or via the L1D Flush
 187 +command. The latter is issued when L1TF mitigation is enabled so the extra
 188 +VERW can be avoided. If the CPU is not affected by L1TF then VERW needs to
 189 +be issued.
 190 +
 191 +If the VERW instruction with the supplied segment selector argument is
 192 +executed on a CPU without the microcode update there is no side effect
 193 +other than a small number of pointlessly wasted CPU cycles.
 194 +
 195 +This does not protect against cross Hyper-Thread attacks except for MSBDS
 196 +which is only exploitable cross Hyper-thread when one of the Hyper-Threads
 197 +enters a C-state.
 198 +
 199 +The kernel provides a function to invoke the buffer clearing:
 200 +
 201 +    mds_clear_cpu_buffers()
 202 +
 203 +The mitigation is invoked on kernel/userspace, hypervisor/guest and C-state
 204 +(idle) transitions.
 205 +
 206 +According to current knowledge additional mitigations inside the kernel
 207 +itself are not required because the necessary gadgets to expose the leaked
 208 +data cannot be controlled in a way which allows exploitation from malicious
 209 +user space or VM guests.
 210 diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
 211 index 14bf299b369f..4d11e89351f1 100644
 212 --- a/arch/x86/include/asm/nospec-branch.h
 213 +++ b/arch/x86/include/asm/nospec-branch.h
 214 @@ -308,6 +308,31 @@ DECLARE_STATIC_KEY_FALSE(switch_to_cond_stibp);
 215  DECLARE_STATIC_KEY_FALSE(switch_mm_cond_ibpb);
 216  DECLARE_STATIC_KEY_FALSE(switch_mm_always_ibpb);
 217
 218 +#include <asm/segment.h>
 219 +
 220 +/**
 221 + * mds_clear_cpu_buffers - Mitigation for MDS vulnerability
 222 + *
 223 + * This uses the otherwise unused and obsolete VERW instruction in
 224 + * combination with microcode which triggers a CPU buffer flush when the
 225 + * instruction is executed.
 226 + */
 227 +static inline void mds_clear_cpu_buffers(void)
 228 +{
 229 +       static const u16 ds = __KERNEL_DS;
 230 +
 231 +       /*
 232 +        * Has to be the memory-operand variant because only that
 233 +        * guarantees the CPU buffer flush functionality according to
 234 +        * documentation. The register-operand variant does not.
 235 +        * Works with any segment selector, but a valid writable
 236 +        * data segment is the fastest variant.
 237 +        *
 238 +        * "cc" clobber is required because VERW modifies ZF.
 239 +        */
 240 +       asm volatile("verw %[ds]" : : [ds] "m" (ds) : "cc");
 241 +}
 242 +
 243  #endif /* __ASSEMBLY__ */
 244
 245  /*
 246 --
 247 2.21.0
 248