From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from aserp2120.oracle.com ([141.146.126.78]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fGqLL-0001kX-93 for speck@linutronix.de; Thu, 10 May 2018 20:31:08 +0200 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w4AIQJst106050 for ; Thu, 10 May 2018 18:30:59 GMT Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2hvth98ab2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 10 May 2018 18:30:59 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w4AIUx8B023612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 10 May 2018 18:30:59 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w4AIUxri026316 for ; Thu, 10 May 2018 18:30:59 GMT Date: Thu, 10 May 2018 14:30:58 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [patch V11 05/16] SSB 5 Message-ID: <20180510183058.GJ27358@char.us.oracle.com> References: <20180502215102.192655950@linutronix.de> <20180502215416.459915781@linutronix.de> <20180510175257.GD13616@tassilo.jf.intel.com> MIME-Version: 1.0 In-Reply-To: <20180510175257.GD13616@tassilo.jf.intel.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Thu, May 10, 2018 at 10:52:57AM -0700, speck for Andi Kleen wrote: > Hi, > > I went over this patch again and I'm not sure i understand > how it works. > > > On Wed, May 02, 2018 at 11:51:07PM +0200, speck for Thomas Gleixner wrote: > > --- a/arch/x86/kvm/vmx.c > > +++ b/arch/x86/kvm/vmx.c > > @@ -9720,8 +9720,7 @@ static void __noclone vmx_vcpu_run(struc > > * is no need to worry about the conditional branch over the wrmsr > > * being speculatively taken. > > */ > > - if (vmx->spec_ctrl) > > - native_wrmsrl(MSR_IA32_SPEC_CTRL, vmx->spec_ctrl); > > + x86_spec_ctrl_set_guest(vmx->spec_ctrl); > > > > vmx->__launched = vmx->loaded_vmcs->launched; > > > > @@ -9869,8 +9868,7 @@ static void __noclone vmx_vcpu_run(struc > > if (unlikely(!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL))) > > vmx->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL); > > > > - if (vmx->spec_ctrl) > > - native_wrmsrl(MSR_IA32_SPEC_CTRL, 0); > > + x86_spec_ctrl_restore_host(vmx->spec_ctrl); > > So we assume that vmx->spec_ctrl is always the correct value of the guest. > > > But vmx_set_msr does .. only if we intercept it. > > vmx->spec_ctrl = data; > > if (!data) > break; > > /* > * For non-nested: > * When it's written (to non-zero) for the first time, pass > * it through. > * > * For nested: > * The handling of the MSR bitmap for L2 guests is done in > * nested_vmx_merge_msr_bitmap. We should not touch the > * vmcs02.msr_bitmap here since it gets completely overwritten > * in the merging. We update the vmcs01 here for L1 as well > * since it will end up touching the MSR anyway now. > */ > vmx_disable_intercept_for_msr(vmx->vmcs01.msr_bitmap, > MSR_IA32_SPEC_CTRL, > MSR_TYPE_RW); > > That means only the value of the first write in the guest is saved in vmx->spec_ctrl. > > But what happens when a later write is different from the first write? This code: if (unlikely(!msr_write_intercepted(vcpu, MSR_IA32_SPEC_CTRL))) vmx->spec_ctrl = native_read_msr(MSR_IA32_SPEC_CTRL); Would read it on the VMEXITs. > > The host wouldn't notice it and force it back to the original value on > the next VMENTRY, silently losing the right state. > > Now with three different bits that can be set dynamically this is highly likely > that the first write is different than later writes. > > On Linux it was ok before SSBD because the only bit that could be set was IBRS > or IBRS_ALL, but on other OS that use STIBP for only some processes it could also > lose the value. With MDD in the picture it can happen on Linux too. > > Do I miss something here? > > -Andi