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 14:44:48 -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 1gxC4F-0004tA-2Y for speck@linutronix.de; Fri, 22 Feb 2019 15:44:47 +0100 Date: Fri, 22 Feb 2019 15:44:37 +0100 From: Greg KH Subject: [MODERATED] Re: [patch V3 9/9] MDS basics 9 Message-ID: <20190222144437.GA14171@kroah.com> References: <20190221234431.922117624@linutronix.de> <20190221235535.207933985@linutronix.de> <20190222075040.GA25676@kroah.com> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Fri, Feb 22, 2019 at 11:38:36AM +0100, speck for Thomas Gleixner wrote: > On Fri, 22 Feb 2019, speck for Greg KH wrote: > > On Fri, Feb 22, 2019 at 12:44:40AM +0100, speck for Thomas Gleixner wrote: > > > 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"? > > I'd prefer not. So the logic here is: > > if CPU not affected: > do nothing > > if 'off': > do nothing > > if 'auto' or 'full': > enable VERW > > The latter has two variants: > > 1) cpuid MD_CLEAR is set > > Switches the internal mode to FULL and VERW provides real protection. > > 2) cpuid MD_CLEAR is not set > > Switches the internal mode to VMWERV, issues VERW which protects or > not. If microcode is not updated the VERW wastes a few cpu cycles > pointlessly. > > The internal state is there so the dmesg/sysfs output reflects the > protection state real vs. lottery. Ok, thanks, that makes more sense. That might want to go into the documentation somewhere :) thanks, greg k-h