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 17:14:21 -0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gwVRs-0002Aj-0Z for speck@linutronix.de; Wed, 20 Feb 2019 18:14:20 +0100 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 4605CAFEF for ; Wed, 20 Feb 2019 17:14:14 +0000 (UTC) Date: Wed, 20 Feb 2019 18:14:03 +0100 From: Borislav Petkov Subject: [MODERATED] Re: [patch V2 03/10] MDS basics+ 3 Message-ID: <20190220171403.GD3304@zn.tnic> 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: quoted-printable 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 >=20 > The Microarchitectural Data Sampling (MDS) vulernabilities are mitigated by vulnerabilities > 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. >=20 > Provide a inline function with the assembly magic. The argument of the VERW an > instruction must be a memory operand. Do we know why it has to be a memop? > Add x86 specific documentation about MDS and the internal workings of the > mitigation. >=20 > Signed-off-by: Thomas Gleixner > --- > V1 --> V2: Add "cc" clobber and documentation > --- > Documentation/index.rst | 1=20 > 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(+) >=20 > --- a/Documentation/index.rst > +++ b/Documentation/index.rst > @@ -101,6 +101,7 @@ implementation. > :maxdepth: 2 > =20 > sh/index > + x86/index > =20 > Filesystem Documentation > ------------------------ > --- /dev/null > +++ b/Documentation/x86/conf.py > @@ -0,0 +1,10 @@ > +# -*- coding: utf-8; mode: python -*- > + > +project =3D "X86 architecture specific documentation" > + > +tags.add("subproject") > + > +latex_documents =3D [ > + ('index', 'x86.tex', project, > + 'The kernel development community', 'manual'), > +] > --- /dev/null > +++ b/Documentation/x86/index.rst > @@ -0,0 +1,8 @@ > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > +x86 architecture specifics > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > + > +.. toctree:: > + :maxdepth: 1 > + > + mds > --- /dev/null > +++ b/Documentation/x86/mds.rst > @@ -0,0 +1,72 @@ > +Microarchitecural Data Sampling (MDS) mitigation > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > + > +Microarchitectural Data Sampling (MDS), is a class of side channel attacks s/,// basically the same nitpicks as to the commit message of patch 1 :). > +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 WARNING: 'preceeding' may be misspelled - perhaps 'preceding'? > +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 maybe s/spared/avoided/ > +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); > =20 > +#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 =3D __KERNEL_DS; > + > + /* > + * Has to be memory form, don't modify to use a register. VERW > + * modifies ZF. Yeah, so did it say somewhere why it has to be memory operation? Would be useful to have it here in the comment. With that: Reviewed-by: Borislav Petkov --=20 Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imend=C3=B6rffer, Jane Smithard, Graham Norton, HR= B 21284 (AG N=C3=BCrnberg) --=20