From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from aserp2130.oracle.com ([141.146.126.79]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1f9ZfS-0001Xc-1U for speck@linutronix.de; Fri, 20 Apr 2018 19:17:51 +0200 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w3KHFu7v072694 for ; Fri, 20 Apr 2018 17:17:42 GMT Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2hf7amu1x3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 20 Apr 2018 17:17:42 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w3KHHf3w007491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 20 Apr 2018 17:17:41 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w3KHHfn4020387 for ; Fri, 20 Apr 2018 17:17:41 GMT Date: Fri, 20 Apr 2018 13:17:36 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: [patch 04/11] [PATCH v2 04/10] Linux Patch #4 Message-ID: <20180420171730.GA5333@localhost.localdomain> References: <20180420022613.057637144@localhost.localdomain> <20180420161533.GK13977@pd.tnic> <20180420163936.GA4615@localhost.localdomain> <20180420170331.GL13977@pd.tnic> MIME-Version: 1.0 In-Reply-To: <20180420170331.GL13977@pd.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: speck@linutronix.de List-ID: On Fri, Apr 20, 2018 at 07:03:31PM +0200, speck for Borislav Petkov wrote: > On Fri, Apr 20, 2018 at 12:39:40PM -0400, speck for Konrad Rzeszutek Wilk w= rote: > > Wouldn't we leak our MD state to the guest? That is the guest > > may have cleared everything (svm->spec_ctrl is zero when we VMEXIT), > > and now we would be running it with MD bit set? >=20 > No, you pass the requested bits: >=20 > x86_enable_ibrs(svm->spec_ctrl); I was thinking of the conditional: if (svm->spec_ctrl) <=3D=3D=3D HERE x86_enable_ibrs(svm->spec_ctrl); Which meant that if the guest had set SPEC_CTRL to zero we would never enter the x86_enable_ibrs function at all and VMENTER in the guest with SPEC_CTRL MDD bit enabled (as we never restored the guest SPEC_CTRL which is zero). Aka, leaking our state in it. Hence thinking to ditch the conditional at all and just have those two accessory functions. >=20 > and that function then picks apart which bits the host supports and sets > them accordingly and filters out the reserved bits. You might call the > function then: >=20 > x86_set_spec_ctrl(); >=20 > and its counterpart >=20 > x86_restore_spec_ctrl(); Right. I am going to assume it would have an 'u64' as parameter. >=20 > or whatever. The restore side would simply clear the IBRS bit as we > don't enable it on the host. It will restore the MD setting for the host > too. >=20 > --=20 > Regards/Gruss, > Boris. >=20 > SUSE Linux GmbH, GF: Felix Imend=C3=B6rffer, Jane Smithard, Graham Norton, = HRB 21284 (AG N=C3=BCrnberg) > --=20