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 00:35:36 -0000 Received: from smtp.ctxuk.citrix.com ([185.25.65.24] helo=SMTP.EU.CITRIX.COM) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gyQic-0004r7-LC for speck@linutronix.de; Tue, 26 Feb 2019 01:35:35 +0100 Subject: [MODERATED] Re: [patch V4 09/11] x86/speculation/mds: Add mitigation mode VMWERV References: <20190222222418.405369026@linutronix.de> <20190222224149.881444221@linutronix.de> <20190225203101.GB6558@mgross-MOBL.amr.corp.intel.com> From: Andrew Cooper Message-ID: <2d41f95e-c282-3a5f-d7d8-7827f2139571@citrix.com> Date: Tue, 26 Feb 2019 00:34:55 +0000 MIME-Version: 1.0 In-Reply-To: <20190225203101.GB6558@mgross-MOBL.amr.corp.intel.com> Content-Type: multipart/mixed; boundary="c4KAowzN2LriMVx2wg4SqAeyprflunZdI"; protected-headers="v1" To: speck@linutronix.de List-ID: --c4KAowzN2LriMVx2wg4SqAeyprflunZdI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-GB 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 wro= te: >> From: Thomas Gleixner >> >> In virtualized environments it can happen that the host has the microc= ode >> update which utilizes the VERW instruction to clear CPU buffers, but t= he >> 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 invocat= ion >> 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 upd= ated, >> 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 s= tate >> the invocation can be enforced or conditional. >> =20 >> +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 kern= el >> itself are not required because the necessary gadgets to expose the l= eaked >> data cannot be controlled in a way which allows exploitation from mal= icious >> user space or VM guests. >> =20 >> + >> +Kernel internal mitigation modes >> +-------------------------------- >> + >> + =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= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> + off Mitigation is disabled. Either the CPU is not affected or >> + mds=3Doff 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. ~Andrew --c4KAowzN2LriMVx2wg4SqAeyprflunZdI--