From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 6/7] x86/svm: Set IBPB when running a different VCPU Date: Tue, 9 Jan 2018 15:47:15 -0500 Message-ID: <20180109204715.GL19756@char.us.oracle.com> References: <74e86dd8-804e-c9f2-098f-773283ac7065@redhat.com> <1255f660-55c5-86f0-07d0-b5846af35c4a@redhat.com> <20180109203909.GG19756@char.us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Arjan van de Ven , Liran Alon , jmattson@google.com, dwmw@amazon.co.uk, bp@alien8.de, aliguori@amazon.com, thomas.lendacky@amd.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org To: Paolo Bonzini , t@char.us.oracle.com Return-path: Content-Disposition: inline In-Reply-To: <20180109203909.GG19756@char.us.oracle.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Tue, Jan 09, 2018 at 03:39:09PM -0500, Konrad Rzeszutek Wilk wrote: > On Tue, Jan 09, 2018 at 05:49:08PM +0100, Paolo Bonzini wrote: > > On 09/01/2018 17:23, Arjan van de Ven wrote: > > > On 1/9/2018 8:17 AM, Paolo Bonzini wrote: > > >> On 09/01/2018 16:19, Arjan van de Ven wrote: > > >>> On 1/9/2018 7:00 AM, Liran Alon wrote: > > >>>> > > >>>> ----- arjan@linux.intel.com wrote: > > >>>> > > >>>>> On 1/9/2018 3:41 AM, Paolo Bonzini wrote: > > >>>>>> The above ("IBRS simply disables the indirect branch predictor= ") > > >>>>>> was my > > >>>>>> take-away message from private discussion with Intel.=A0 My gu= ess is > > >>>>>> that > > >>>>>> the vendors are just handwaving a spec that doesn't match what > > >>>>>> they have > > >>>>>> implemented, because honestly a microcode update is unlikely t= o do > > >>>>>> much > > >>>>>> more than an old-fashioned chicken bit.=A0 Maybe on Skylake it= does > > >>>>>> though, since the performance characteristics of IBRS are so > > >>>>>> different > > >>>>>> from previous processors.=A0 Let's ask Arjan who might have mo= re > > >>>>>> information about it, and hope he actually can disclose it... > > >>>>> > > >>>>> IBRS will ensure that, when set after the ring transition, no e= arlier > > >>>>> branch prediction data is used for indirect branches while IBRS= is > > >>>>> set > > >> > > >> Let me ask you my questions, which are independent of L0/L1/L2 > > >> terminology. > > >> > > >> 1) Is vmentry/vmexit considered a ring transition, even if the gue= st is > > >> running in ring 0?=A0 If IBRS=3D1 in the guest and the host is usi= ng IBRS, > > >> the host will not do a wrmsr on exit.=A0 Is this safe for the host= kernel? > > >=20 > > > I think the CPU folks would want us to write the msr again. > >=20 > > Want us, or need us---and if we don't do that, what happens? And if = we > > have to do it, how is IBRS=3D1 different from an IBPB?... >=20 > Arjan says 'ring transition' but I am pretty sure it is more of 'predic= tion > mode change'. And from what I have gathered so far moving from lower (g= uest) > to higher (hypervisor) has no bearing on the branch predicator. Meaning > the guest ring0 can attack us if we don't touch this MSR. >=20 > We have to WRMSR 0x48 to 1 to flush out lower prediction. Aka this is a > 'reset' button and at every 'prediction mode' you have to hit this. I suppose means that when we VMENTER the original fix (where we compare the host to guest) can stay - as we entering an lower prediction mode. I wonder then what does writting 0 do to it? A nop? >=20 >=20 > Can we have a discussion on making an kvm-security mailing list > where we can figure all this out during embargo and not have these > misunderstandings. >=20 > >=20 > > Since I am at it, what happens on *current generation* CPUs if you > > always leave IBRS=3D1? Slow and safe, or fast and unsafe? > >=20 > > >> 2) How will the future processors work where IBRS should always be= =3D1? > > >=20 > > > IBRS=3D1 should be "fire and forget this ever happened". > > > This is the only time anyone should use IBRS in practice > >=20 > > And IBPB too I hope? But besides that, I need to know exactly how th= at > > is implemented to ensure that it's doing the right thing. > >=20 > > > (and then the host turns it on and makes sure to not expose it to t= he > > > guests I hope) > >=20 > > That's not that easy, because guests might have support for SPEC_CTRL > > but not for IA32_ARCH_CAPABILITIES. > >=20 > > You could disable the SPEC_CTRL bit, but then the guest might think i= t > > is not secure. It might also actually *be* insecure, if you migrated= to > > an older CPU where IBRS is not fire-and-forget. > >=20 > > Paolo