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 ; 22 Feb 2019 07:50:51 -0000 Received: from mail.kernel.org ([198.145.29.99]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gx5bd-00082d-Io for speck@linutronix.de; Fri, 22 Feb 2019 08:50:50 +0100 Date: Fri, 22 Feb 2019 08:50:40 +0100 From: Greg KH Subject: [MODERATED] Re: [patch V3 9/9] MDS basics 9 Message-ID: <20190222075040.GA25676@kroah.com> References: <20190221234431.922117624@linutronix.de> <20190221235535.207933985@linutronix.de> MIME-Version: 1.0 In-Reply-To: <20190221235535.207933985@linutronix.de> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, Feb 22, 2019 at 12:44:40AM +0100, speck for Thomas Gleixner wrote: > Subject: [patch V3 9/9] x86/speculation/mds: Add mitigation mode VMWERV > From: Thomas Gleixner > > In virtualized environments it can happen that the host has the microcode > update which utilizes the VERW instruction to clear CPU buffers, but the > hypervisor is not yet updated to expose the X86_FEATURE_MD_CLEAR CPUID bit > to guests. > > Introduce an internal mitigation mode 'VWWERV' which enables the invocation > of the CPU buffer clearing even if X86_FEATURE_MD_CLEAR is not set. If the > system has no updated microcode this results in a pointless execution of > the VERW instruction wasting a few CPU cycles. If the microcode is updated, > but not exposed to a guest then the CPU buffers will be cleared. > > That said: Virtual Machines Will Eventually Receive Vaccine > > Signed-off-by: Thomas Gleixner > --- > V2 -> V3: Rename mode. Nice name :) > --- > Documentation/x86/mds.rst | 5 +++++ > arch/x86/include/asm/processor.h | 1 + > arch/x86/kernel/cpu/bugs.c | 14 ++++++++------ > 3 files changed, 14 insertions(+), 6 deletions(-) > > --- a/Documentation/x86/mds.rst > +++ b/Documentation/x86/mds.rst > @@ -88,6 +88,11 @@ The mitigation is invoked on kernel/user > (idle) transitions. Depending on the mitigation mode and the system state > the invocation can be enforced or conditional. > > +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 work. 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 > --- a/arch/x86/include/asm/processor.h > +++ b/arch/x86/include/asm/processor.h > @@ -996,6 +996,7 @@ enum mds_mitigations { > MDS_MITIGATION_OFF, > MDS_MITIGATION_AUTO, > MDS_MITIGATION_FULL, > + MDS_MITIGATION_VMWERV, > }; > > #endif /* _ASM_X86_PROCESSOR_H */ > --- a/arch/x86/kernel/cpu/bugs.c > +++ b/arch/x86/kernel/cpu/bugs.c > @@ -221,7 +221,8 @@ static enum mds_mitigations mds_mitigati > > static const char * const mds_strings[] = { > [MDS_MITIGATION_OFF] = "Vulnerable", > - [MDS_MITIGATION_FULL] = "Mitigation: Clear CPU buffers" > + [MDS_MITIGATION_FULL] = "Mitigation: Clear CPU buffers", > + [MDS_MITIGATION_VMWERV] = "Vulnerable: Clear CPU buffers attempted, no microcode", > }; > > static void mds_select_mitigation(void) > @@ -236,12 +237,12 @@ static void mds_select_mitigation(void) > break; > case MDS_MITIGATION_AUTO: > case MDS_MITIGATION_FULL: > - if (boot_cpu_has(X86_FEATURE_MD_CLEAR)) { > + case MDS_MITIGATION_VMWERV: > + if (boot_cpu_has(X86_FEATURE_MD_CLEAR)) > mds_mitigation = MDS_MITIGATION_FULL; > - static_branch_enable(&mds_user_clear); > - } else { > - mds_mitigation = MDS_MITIGATION_OFF; > - } > + else > + mds_mitigation = MDS_MITIGATION_VMWERV; > + static_branch_enable(&mds_user_clear); So did we just loose the ability at "auto" to turn this off if present, because we really do not know if we can turn it off automatically? Or am I reading this code wrong? Should there be a new usespace command line option for "vmwerv"? thanks, greg k-h