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 ; 04 Mar 2019 05:47:29 -0000 Received: from mx1.redhat.com ([209.132.183.28]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1h0gRk-00017v-7F for speck@linutronix.de; Mon, 04 Mar 2019 06:47:28 +0100 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8D22D308FF14 for ; Mon, 4 Mar 2019 05:47:21 +0000 (UTC) Received: from tonnant.bos.jonmasters.org (ovpn-120-248.rdu2.redhat.com [10.10.120.248]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3660A19C58 for ; Mon, 4 Mar 2019 05:47:21 +0000 (UTC) References: <20190301214738.281554861@linutronix.de> <20190301214848.253554490@linutronix.de> From: Jon Masters Message-ID: Date: Mon, 4 Mar 2019 00:47:16 -0500 MIME-Version: 1.0 In-Reply-To: <20190301214848.253554490@linutronix.de> Subject: [MODERATED] Encrypted Message Content-Type: multipart/mixed; boundary="5VkVOZqTt292UlMWoSJEDlnDMDOuR49im"; protected-headers="v1" To: speck@linutronix.de List-ID: This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --5VkVOZqTt292UlMWoSJEDlnDMDOuR49im Content-Type: text/rfc822-headers; protected-headers="v1" Content-Disposition: inline From: Jon Masters To: speck for Thomas Gleixner Subject: Re: [patch V6 12/14] MDS basics 12 --5VkVOZqTt292UlMWoSJEDlnDMDOuR49im Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/1/19 4:47 PM, speck for Thomas Gleixner wrote: > Subject: [patch V6 12/14] x86/speculation/mds: Add mitigation mode VMWE= RV > From: Thomas Gleixner >=20 > In virtualized environments it can happen that the host has the microco= de > update which utilizes the VERW instruction to clear CPU buffers, but th= e > hypervisor is not yet updated to expose the X86_FEATURE_MD_CLEAR CPUID = bit > to guests. >=20 > Introduce an internal mitigation mode VWWERV which enables the invocati= on > 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 o= f > the VERW instruction wasting a few CPU cycles. If the microcode is upda= ted, > but not exposed to a guest then the CPU buffers will be cleared. >=20 > That said: Virtual Machines Will Eventually Receive Vaccine The effect of this patch, currently, is that a (bare metal) machine without updated ucode will print the following: [ 1.576602] MDS: Vulnerable: Clear CPU buffers attempted, no microcode= The intention of the patch is to say "hey, you might be on a VM, so we'll try anyway in case we didn't get told you had MD_CLEAR". But the effect on bare metal might be ambiguous. It's reasonable (for someone else) to assume we might be using a software sequence to try flushing. Perhaps the wording should convey something like: "MDS: Vulnerable: Clear CPU buffers may not work, no microcode" Jon. --=20 Computer Architect | Sent with my Fedora powered laptop --5VkVOZqTt292UlMWoSJEDlnDMDOuR49im--