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 20:05:48 -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 1gwY7n-0007Ns-8l for speck@linutronix.de; Wed, 20 Feb 2019 21:05:47 +0100 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 42567AC6F for ; Wed, 20 Feb 2019 20:05:41 +0000 (UTC) Date: Wed, 20 Feb 2019 21:05:31 +0100 From: Borislav Petkov Subject: [MODERATED] Re: [patch V2 05/10] MDS basics+ 5 Message-ID: <20190220200531.GG3304@zn.tnic> References: <20190220150753.665964899@linutronix.de> <20190220151400.409678548@linutronix.de> MIME-Version: 1.0 In-Reply-To: <20190220151400.409678548@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:58PM +0100, speck for Thomas Gleixner wrote: > Subject: [patch V2 05/10] x86/speculation/mds: Conditionaly clear CPU buffe= rs on idle entry WARNING: 'Conditionaly' may be misspelled - perhaps 'Conditionally'? > From: Thomas Gleixner >=20 > Add a static key which controls the invocation of the CPU buffer clear > mechanism on idle entry. This is independent of other MDS mitigations > because the idle entry invocation to mitigate the potential leakage due to > store buffer repartitioning is only necessary on SMT systems. >=20 > Add the actual invocations to the different halt/mwait variants which > covers all usage sites. mwaitx is not patched as it's not available on > Intel CPUs. >=20 > The buffer clear is only invoked before entering the C-State to prevent > that stale data from the idling CPU can be spilled to the Hyper-Thread s/can // > sibling after the Store buffer got repartitioned and all entries are > available to the non idle sibling. >=20 > When coming out of idle the store buffer is partitioned again so each > sibling has half of it available. Now the back from idle CPU could be "Now the CPU which returned from idle... " > speculatively exposed to contents of the sibling, but the buffers are > flushed either on exit to user space or on VMENTER. >=20 > When later on conditional buffer clearing is implemented on top of this, > then there is no action required either because before returning to user > space the context switch will set the condition flag which causes a flush > on the return to user path. >=20 > This intentionaly does not handle the case in the acpi/processor_idle > driver which uses the legacy IO port interface for C-State transitions for > two reasons: >=20 > - The acpi/processor_idle driver was replaced by the intel_idle driver > almost a decade ago. Anything Nehalem upwards supports it and defaults > to that new driver. >=20 > - The legacy IO port interface is likely to be used on older and therefore > unaffected CPUs or on systems which do not receive microcode updates > anymore, so there is no point in adding that. >=20 > Signed-off-by: Thomas Gleixner > --- > Documentation/x86/mds.rst | 33 ++++++++++++++++++++++++++++++= +++ > arch/x86/include/asm/irqflags.h | 4 ++++ > arch/x86/include/asm/mwait.h | 7 +++++++ > arch/x86/include/asm/nospec-branch.h | 12 ++++++++++++ > arch/x86/kernel/cpu/bugs.c | 2 ++ > 5 files changed, 58 insertions(+) >=20 > --- a/Documentation/x86/mds.rst > +++ b/Documentation/x86/mds.rst > @@ -143,3 +143,36 @@ Mitigation points > =20 > None of those are controllable by unpriviledged attackers to form a > reliable exploit surface. > + > +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-Thread enters a "... one of the Hyper-Threads... " > + 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 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 can be spilled 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. Now the back from idle CPU could be > + speculatively exposed to contents of the sibling, but the buffers are > + flushed either on exit to user space or on VMENTER. > + > + 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 superseeded by the intel_idle driver around 2010 and is WARNING: 'superseeded' may be misspelled - perhaps 'superseded'? > + preferred on all affected CPUs which still receive microcode updates > + (Nehalem onwards). 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. With that addressed: 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