210 lines · plain
1Microarchitectural Data Sampling (MDS) mitigation2=================================================3 4.. _mds:5 6Overview7--------8 9Microarchitectural Data Sampling (MDS) is a family of side channel attacks10on internal buffers in Intel CPUs. The variants are:11 12 - Microarchitectural Store Buffer Data Sampling (MSBDS) (CVE-2018-12126)13 - Microarchitectural Fill Buffer Data Sampling (MFBDS) (CVE-2018-12130)14 - Microarchitectural Load Port Data Sampling (MLPDS) (CVE-2018-12127)15 - Microarchitectural Data Sampling Uncacheable Memory (MDSUM) (CVE-2019-11091)16 17MSBDS leaks Store Buffer Entries which can be speculatively forwarded to a18dependent load (store-to-load forwarding) as an optimization. The forward19can also happen to a faulting or assisting load operation for a different20memory address, which can be exploited under certain conditions. Store21buffers are partitioned between Hyper-Threads so cross thread forwarding is22not possible. But if a thread enters or exits a sleep state the store23buffer is repartitioned which can expose data from one thread to the other.24 25MFBDS leaks Fill Buffer Entries. Fill buffers are used internally to manage26L1 miss situations and to hold data which is returned or sent in response27to a memory or I/O operation. Fill buffers can forward data to a load28operation and also write data to the cache. When the fill buffer is29deallocated it can retain the stale data of the preceding operations which30can then be forwarded to a faulting or assisting load operation, which can31be exploited under certain conditions. Fill buffers are shared between32Hyper-Threads so cross thread leakage is possible.33 34MLPDS leaks Load Port Data. Load ports are used to perform load operations35from memory or I/O. The received data is then forwarded to the register36file or a subsequent operation. In some implementations the Load Port can37contain stale data from a previous operation which can be forwarded to38faulting or assisting loads under certain conditions, which again can be39exploited eventually. Load ports are shared between Hyper-Threads so cross40thread leakage is possible.41 42MDSUM is a special case of MSBDS, MFBDS and MLPDS. An uncacheable load from43memory that takes a fault or assist can leave data in a microarchitectural44structure that may later be observed using one of the same methods used by45MSBDS, MFBDS or MLPDS.46 47Exposure assumptions48--------------------49 50It is assumed that attack code resides in user space or in a guest with one51exception. The rationale behind this assumption is that the code construct52needed for exploiting MDS requires:53 54 - to control the load to trigger a fault or assist55 56 - to have a disclosure gadget which exposes the speculatively accessed57 data for consumption through a side channel.58 59 - to control the pointer through which the disclosure gadget exposes the60 data61 62The existence of such a construct in the kernel cannot be excluded with63100% certainty, but the complexity involved makes it extremely unlikely.64 65There is one exception, which is untrusted BPF. The functionality of66untrusted BPF is limited, but it needs to be thoroughly investigated67whether it can be used to create such a construct.68 69 70Mitigation strategy71-------------------72 73All variants have the same mitigation strategy at least for the single CPU74thread case (SMT off): Force the CPU to clear the affected buffers.75 76This is achieved by using the otherwise unused and obsolete VERW77instruction in combination with a microcode update. The microcode clears78the affected CPU buffers when the VERW instruction is executed.79 80For virtualization there are two ways to achieve CPU buffer81clearing. Either the modified VERW instruction or via the L1D Flush82command. The latter is issued when L1TF mitigation is enabled so the extra83VERW can be avoided. If the CPU is not affected by L1TF then VERW needs to84be issued.85 86If the VERW instruction with the supplied segment selector argument is87executed on a CPU without the microcode update there is no side effect88other than a small number of pointlessly wasted CPU cycles.89 90This does not protect against cross Hyper-Thread attacks except for MSBDS91which is only exploitable cross Hyper-thread when one of the Hyper-Threads92enters a C-state.93 94The kernel provides a function to invoke the buffer clearing:95 96 mds_clear_cpu_buffers()97 98Also macro CLEAR_CPU_BUFFERS can be used in ASM late in exit-to-user path.99Other than CFLAGS.ZF, this macro doesn't clobber any registers.100 101The mitigation is invoked on kernel/userspace, hypervisor/guest and C-state102(idle) transitions.103 104As a special quirk to address virtualization scenarios where the host has105the microcode updated, but the hypervisor does not (yet) expose the106MD_CLEAR CPUID bit to guests, the kernel issues the VERW instruction in the107hope that it might actually clear the buffers. The state is reflected108accordingly.109 110According to current knowledge additional mitigations inside the kernel111itself are not required because the necessary gadgets to expose the leaked112data cannot be controlled in a way which allows exploitation from malicious113user space or VM guests.114 115Kernel internal mitigation modes116--------------------------------117 118 ======= ============================================================119 off Mitigation is disabled. Either the CPU is not affected or120 mds=off is supplied on the kernel command line121 122 full Mitigation is enabled. CPU is affected and MD_CLEAR is123 advertised in CPUID.124 125 vmwerv Mitigation is enabled. CPU is affected and MD_CLEAR is not126 advertised in CPUID. That is mainly for virtualization127 scenarios where the host has the updated microcode but the128 hypervisor does not expose MD_CLEAR in CPUID. It's a best129 effort approach without guarantee.130 ======= ============================================================131 132If the CPU is affected and mds=off is not supplied on the kernel command133line then the kernel selects the appropriate mitigation mode depending on134the availability of the MD_CLEAR CPUID bit.135 136Mitigation points137-----------------138 1391. Return to user space140^^^^^^^^^^^^^^^^^^^^^^^141 142 When transitioning from kernel to user space the CPU buffers are flushed143 on affected CPUs when the mitigation is not disabled on the kernel144 command line. The mitigation is enabled through the feature flag145 X86_FEATURE_CLEAR_CPU_BUF.146 147 The mitigation is invoked just before transitioning to userspace after148 user registers are restored. This is done to minimize the window in149 which kernel data could be accessed after VERW e.g. via an NMI after150 VERW.151 152 **Corner case not handled**153 Interrupts returning to kernel don't clear CPUs buffers since the154 exit-to-user path is expected to do that anyways. But, there could be155 a case when an NMI is generated in kernel after the exit-to-user path156 has cleared the buffers. This case is not handled and NMI returning to157 kernel don't clear CPU buffers because:158 159 1. It is rare to get an NMI after VERW, but before returning to userspace.160 2. For an unprivileged user, there is no known way to make that NMI161 less rare or target it.162 3. It would take a large number of these precisely-timed NMIs to mount163 an actual attack. There's presumably not enough bandwidth.164 4. The NMI in question occurs after a VERW, i.e. when user state is165 restored and most interesting data is already scrubbed. What's left166 is only the data that NMI touches, and that may or may not be of167 any interest.168 169 1702. C-State transition171^^^^^^^^^^^^^^^^^^^^^172 173 When a CPU goes idle and enters a C-State the CPU buffers need to be174 cleared on affected CPUs when SMT is active. This addresses the175 repartitioning of the store buffer when one of the Hyper-Threads enters176 a C-State.177 178 When SMT is inactive, i.e. either the CPU does not support it or all179 sibling threads are offline CPU buffer clearing is not required.180 181 The idle clearing is enabled on CPUs which are only affected by MSBDS182 and not by any other MDS variant. The other MDS variants cannot be183 protected against cross Hyper-Thread attacks because the Fill Buffer and184 the Load Ports are shared. So on CPUs affected by other variants, the185 idle clearing would be a window dressing exercise and is therefore not186 activated.187 188 The invocation is controlled by the static key mds_idle_clear which is189 switched depending on the chosen mitigation mode and the SMT state of190 the system.191 192 The buffer clear is only invoked before entering the C-State to prevent193 that stale data from the idling CPU from spilling to the Hyper-Thread194 sibling after the store buffer got repartitioned and all entries are195 available to the non idle sibling.196 197 When coming out of idle the store buffer is partitioned again so each198 sibling has half of it available. The back from idle CPU could be then199 speculatively exposed to contents of the sibling. The buffers are200 flushed either on exit to user space or on VMENTER so malicious code201 in user space or the guest cannot speculatively access them.202 203 The mitigation is hooked into all variants of halt()/mwait(), but does204 not cover the legacy ACPI IO-Port mechanism because the ACPI idle driver205 has been superseded by the intel_idle driver around 2010 and is206 preferred on all affected CPUs which are expected to gain the MD_CLEAR207 functionality in microcode. Aside of that the IO-Port mechanism is a208 legacy interface which is only used on older systems which are either209 not affected or do not receive microcode updates anymore.210