From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (146.0.238.70:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 20 Feb 2019 16:54:59 -0000 Received: from mga18.intel.com ([134.134.136.126]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gwV97-0001J4-Bf for speck@linutronix.de; Wed, 20 Feb 2019 17:54:58 +0100 Date: Wed, 20 Feb 2019 08:54:53 -0800 From: mark gross Subject: [MODERATED] Re: [patch V2 03/10] MDS basics+ 3 Message-ID: <20190220165453.GA127@mgross-MOBL.amr.corp.intel.com> Reply-To: mgross@linux.intel.com References: <20190220150753.665964899@linutronix.de> <20190220151400.217101404@linutronix.de> MIME-Version: 1.0 In-Reply-To: <20190220151400.217101404@linutronix.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Feb 20, 2019 at 04:07:56PM +0100, speck for Thomas Gleixner wrote: > Subject: [patch V2 03/10] x86/speculation/mds: Add mds_clear_cpu_buffer() > From: Thomas Gleixner > > The Microarchitectural Data Sampling (MDS) vulernabilities are mitigated by > clearing the affected CPU buffers. The mechanism for clearing the buffers > uses the unused and obsolete VERW instruction in combination with a > microcode update which triggers a CPU buffer clear when VERW is executed. > > Provide a inline function with the assembly magic. The argument of the VERW > instruction must be a memory operand. > > Add x86 specific documentation about MDS and the internal workings of the > mitigation. > > Signed-off-by: Thomas Gleixner > --- > V1 --> V2: Add "cc" clobber and documentation > --- > Documentation/index.rst | 1 > Documentation/x86/conf.py | 10 ++++ > Documentation/x86/index.rst | 8 +++ > Documentation/x86/mds.rst | 72 +++++++++++++++++++++++++++++++++++ > arch/x86/include/asm/nospec-branch.h | 20 +++++++++ > 5 files changed, 111 insertions(+) > > --- a/Documentation/index.rst > +++ b/Documentation/index.rst > @@ -101,6 +101,7 @@ implementation. > :maxdepth: 2 > > sh/index > + x86/index > > Filesystem Documentation > ------------------------ > --- /dev/null > +++ b/Documentation/x86/conf.py > @@ -0,0 +1,10 @@ > +# -*- coding: utf-8; mode: python -*- > + > +project = "X86 architecture specific documentation" > + > +tags.add("subproject") > + > +latex_documents = [ > + ('index', 'x86.tex', project, > + 'The kernel development community', 'manual'), > +] > --- /dev/null > +++ b/Documentation/x86/index.rst > @@ -0,0 +1,8 @@ > +========================== > +x86 architecture specifics > +========================== > + > +.. toctree:: > + :maxdepth: 1 > + > + mds > --- /dev/null > +++ b/Documentation/x86/mds.rst > @@ -0,0 +1,72 @@ > +Microarchitecural Data Sampling (MDS) mitigation > +================================================ > + > +Microarchitectural Data Sampling (MDS), is a class 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 (MLPDS) (CVE-2018-12127) > + > +MSBDS leaks Store Buffer Entries which can be speculatively forwarded to a > +dependent load (store-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 partitionened between Hyper-Threads so cross thread forwarding > +is not possible. But if a thread enters or exits a sleep state the store > +buffer is repartioned 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 preceeding 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. > + > +MLDPS 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. > + > +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 spared. 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. Depending on the mitigation mode and the system state > +the invocation can be enforced or conditional. > + > +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. > + > --- a/arch/x86/include/asm/nospec-branch.h > +++ b/arch/x86/include/asm/nospec-branch.h > @@ -318,6 +318,26 @@ DECLARE_STATIC_KEY_FALSE(switch_to_cond_ > DECLARE_STATIC_KEY_FALSE(switch_mm_cond_ibpb); > DECLARE_STATIC_KEY_FALSE(switch_mm_always_ibpb); > > +#include > + > +/** > + * mds_clear_cpu_buffers - Mitigation for MDS vulnerability > + * > + * This uses the otherwise unused and obsolete VERW instruction in > + * combination with microcode which triggers a CPU buffer flush when the > + * instruction is executed. > + */ > +static inline void mds_clear_cpu_buffers(void) > +{ > + static const u16 ds = __KERNEL_DS; > + > + /* > + * Has to be memory form, don't modify to use a register. VERW > + * modifies ZF. > + */ > + asm volatile("verw %[ds]" : : "i" (0), [ds] "m" (ds) : "cc"); > +} > + > #endif /* __ASSEMBLY__ */ > > /* > Perhaps a dumb question but, is there any point to including that fall back ASM altrinitive for platfroms without the uCode update enabling verw to clear buffers? --mark