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 ; 26 Feb 2019 18:51:57 -0000 Received: from mga05.intel.com ([192.55.52.43]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gyhpb-0008BJ-Ni for speck@linutronix.de; Tue, 26 Feb 2019 19:51:56 +0100 Date: Tue, 26 Feb 2019 10:51:49 -0800 From: mark gross Subject: [MODERATED] Re: [patch V4 09/11] x86/speculation/mds: Add mitigation mode VMWERV Message-ID: <20190226185149.GA94@mgross-MOBL.amr.corp.intel.com> Reply-To: mgross@linux.intel.com References: <20190222222418.405369026@linutronix.de> <20190222224149.881444221@linutronix.de> <20190225203101.GB6558@mgross-MOBL.amr.corp.intel.com> <2d41f95e-c282-3a5f-d7d8-7827f2139571@citrix.com> MIME-Version: 1.0 In-Reply-To: <2d41f95e-c282-3a5f-d7d8-7827f2139571@citrix.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Tue, Feb 26, 2019 at 12:34:55AM +0000, speck for Andrew Cooper wrote: > On 25/02/2019 20:31, speck for mark gross wrote: > > On Fri, Feb 22, 2019 at 11:24:27PM +0100, speck for Thomas Gleixner wrote: > >> 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. > >> --- > >> Documentation/x86/mds.rst | 29 +++++++++++++++++++++++++++++ > >> arch/x86/include/asm/processor.h | 1 + > >> arch/x86/kernel/cpu/bugs.c | 14 ++++++++------ > >> 3 files changed, 38 insertions(+), 6 deletions(-) > >> > >> --- a/Documentation/x86/mds.rst > >> +++ b/Documentation/x86/mds.rst > >> @@ -90,11 +90,40 @@ 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 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 eanbled. CPU is affected and MD_CLEAR is > >> + advertised in CPUID. > >> + > >> + vmwerv Mitigation is enabled. CPU is affected and MD_CLEAR is not > > vmverw <-- type oh? > > I recommend re-reading the commit message :) > > The position of the W isn't an accident. Virtual Machines Will Eventually Receive Vaccine (VMWERV) I get it now. meh, --mark