123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193 |
- Microarchitectural Data Sampling (MDS) mitigation
- =================================================
- .. _mds:
- Overview
- --------
- Microarchitectural Data Sampling (MDS) is a family of side channel attacks
- on internal buffers in Intel CPUs. The variants are:
- - Microarchitectural Store Buffer Data Sampling (MSBDS) (CVE-2018-12126)
- - Microarchitectural Fill Buffer Data Sampling (MFBDS) (CVE-2018-12130)
- - Microarchitectural Load Port Data Sampling (MLPDS) (CVE-2018-12127)
- - Microarchitectural Data Sampling Uncacheable Memory (MDSUM) (CVE-2019-11091)
- MSBDS leaks Store Buffer Entries which can be speculatively forwarded to a
- dependent load (store-to-load forwarding) as an optimization. The forward
- can also happen to a faulting or assisting load operation for a different
- memory address, which can be exploited under certain conditions. Store
- buffers are partitioned between Hyper-Threads so cross thread forwarding is
- not possible. But if a thread enters or exits a sleep state the store
- buffer is repartitioned which can expose data from one thread to the other.
- MFBDS leaks Fill Buffer Entries. Fill buffers are used internally to manage
- L1 miss situations and to hold data which is returned or sent in response
- to a memory or I/O operation. Fill buffers can forward data to a load
- operation and also write data to the cache. When the fill buffer is
- deallocated it can retain the stale data of the preceding operations which
- can then be forwarded to a faulting or assisting load operation, which can
- be exploited under certain conditions. Fill buffers are shared between
- Hyper-Threads so cross thread leakage is possible.
- MLPDS leaks Load Port Data. Load ports are used to perform load operations
- from memory or I/O. The received data is then forwarded to the register
- file or a subsequent operation. In some implementations the Load Port can
- contain stale data from a previous operation which can be forwarded to
- faulting or assisting loads under certain conditions, which again can be
- exploited eventually. Load ports are shared between Hyper-Threads so cross
- thread leakage is possible.
- MDSUM is a special case of MSBDS, MFBDS and MLPDS. An uncacheable load from
- memory that takes a fault or assist can leave data in a microarchitectural
- structure that may later be observed using one of the same methods used by
- MSBDS, MFBDS or MLPDS.
- Exposure assumptions
- --------------------
- It is assumed that attack code resides in user space or in a guest with one
- exception. The rationale behind this assumption is that the code construct
- needed for exploiting MDS requires:
- - to control the load to trigger a fault or assist
- - to have a disclosure gadget which exposes the speculatively accessed
- data for consumption through a side channel.
- - to control the pointer through which the disclosure gadget exposes the
- data
- The existence of such a construct in the kernel cannot be excluded with
- 100% certainty, but the complexity involved makes it extremly unlikely.
- There is one exception, which is untrusted BPF. The functionality of
- untrusted BPF is limited, but it needs to be thoroughly investigated
- whether it can be used to create such a construct.
- Mitigation strategy
- -------------------
- All variants have the same mitigation strategy at least for the single CPU
- thread case (SMT off): Force the CPU to clear the affected buffers.
- This is achieved by using the otherwise unused and obsolete VERW
- instruction in combination with a microcode update. The microcode clears
- the affected CPU buffers when the VERW instruction is executed.
- For virtualization there are two ways to achieve CPU buffer
- clearing. Either the modified VERW instruction or via the L1D Flush
- command. The latter is issued when L1TF mitigation is enabled so the extra
- VERW can be avoided. If the CPU is not affected by L1TF then VERW needs to
- be issued.
- If the VERW instruction with the supplied segment selector argument is
- executed on a CPU without the microcode update there is no side effect
- other than a small number of pointlessly wasted CPU cycles.
- This does not protect against cross Hyper-Thread attacks except for MSBDS
- which is only exploitable cross Hyper-thread when one of the Hyper-Threads
- enters a C-state.
- The kernel provides a function to invoke the buffer clearing:
- mds_clear_cpu_buffers()
- The mitigation is invoked on kernel/userspace, hypervisor/guest and C-state
- (idle) transitions.
- As a special quirk to address virtualization scenarios where the host has
- the microcode updated, but the hypervisor does not (yet) expose the
- MD_CLEAR CPUID bit to guests, the kernel issues the VERW instruction in the
- hope that it might actually clear the buffers. The state is reflected
- accordingly.
- According to current knowledge additional mitigations inside the kernel
- itself are not required because the necessary gadgets to expose the leaked
- data cannot be controlled in a way which allows exploitation from malicious
- user space or VM guests.
- Kernel internal mitigation modes
- --------------------------------
- ======= ============================================================
- off Mitigation is disabled. Either the CPU is not affected or
- mds=off is supplied on the kernel command line
- full Mitigation is enabled. CPU is affected and MD_CLEAR is
- advertised in CPUID.
- vmwerv Mitigation is enabled. CPU is affected and MD_CLEAR is not
- advertised in CPUID. That is mainly for virtualization
- scenarios where the host has the updated microcode but the
- hypervisor does not expose MD_CLEAR in CPUID. It's a best
- effort approach without guarantee.
- ======= ============================================================
- If the CPU is affected and mds=off is not supplied on the kernel command
- line then the kernel selects the appropriate mitigation mode depending on
- the availability of the MD_CLEAR CPUID bit.
- Mitigation points
- -----------------
- 1. Return to user space
- ^^^^^^^^^^^^^^^^^^^^^^^
- When transitioning from kernel to user space the CPU buffers are flushed
- on affected CPUs when the mitigation is not disabled on the kernel
- command line. The migitation is enabled through the static key
- mds_user_clear.
- The mitigation is invoked in prepare_exit_to_usermode() which covers
- all but one of the kernel to user space transitions. The exception
- is when we return from a Non Maskable Interrupt (NMI), which is
- handled directly in do_nmi().
- (The reason that NMI is special is that prepare_exit_to_usermode() can
- enable IRQs. In NMI context, NMIs are blocked, and we don't want to
- enable IRQs with NMIs blocked.)
- 2. C-State transition
- ^^^^^^^^^^^^^^^^^^^^^
- When a CPU goes idle and enters a C-State the CPU buffers need to be
- cleared on affected CPUs when SMT is active. This addresses the
- repartitioning of the store buffer when one of the Hyper-Threads enters
- a C-State.
- When SMT is inactive, i.e. either the CPU does not support it or all
- sibling threads are offline CPU buffer clearing is not required.
- The idle clearing is enabled on CPUs which are only affected by MSBDS
- and not by any other MDS variant. The other MDS variants cannot be
- protected against cross Hyper-Thread attacks because the Fill Buffer and
- the Load Ports are shared. So on CPUs affected by other variants, the
- idle clearing would be a window dressing exercise and is therefore not
- activated.
- The invocation is controlled by the static key mds_idle_clear which is
- switched depending on the chosen mitigation mode and the SMT state of
- the system.
- The buffer clear is only invoked before entering the C-State to prevent
- that stale data from the idling CPU from spilling to the Hyper-Thread
- sibling after the store buffer got repartitioned and all entries are
- available to the non idle sibling.
- When coming out of idle the store buffer is partitioned again so each
- sibling has half of it available. The back from idle CPU could be then
- speculatively exposed to contents of the sibling. The buffers are
- flushed either on exit to user space or on VMENTER so malicious code
- in user space or the guest cannot speculatively access them.
- The mitigation is hooked into all variants of halt()/mwait(), but does
- not cover the legacy ACPI IO-Port mechanism because the ACPI idle driver
- has been superseded by the intel_idle driver around 2010 and is
- preferred on all affected CPUs which are expected to gain the MD_CLEAR
- functionality in microcode. Aside of that the IO-Port mechanism is a
- legacy interface which is only used on older systems which are either
- not affected or do not receive microcode updates anymore.
|