From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Subject: Re: [intel-sgx-kernel-dev] [PATCH 08/10] kvm: vmx: add guest's IA32_SGXLEPUBKEYHASHn runtime switch support Date: Tue, 13 Jun 2017 13:13:04 -0700 Message-ID: <1497384784.23465.29.camel@intel.com> References: <0b4697b9-0976-c8ad-e26f-4ff683318486@linux.intel.com> <20170608123101.47pgsaovkgtdxaw4@intel.com> <46bdaa22-8e7d-738f-9dd0-840fe3327506@linux.intel.com> <20170610122306.lfjshzepqxxyqj72@intel.com> <001ecd91-15e7-ef5a-097b-d57bc7784f47@linux.intel.com> <20170612083658.vrrcr6dq6axiovse@intel.com> <3bbe95fe-bb97-d430-e9d3-d4edcb381f46@linux.intel.com> <20170613185718.25p3zcqlhh2unhnx@intel.com> <20170613190550.2yxdpvcgeddyx3lv@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: kvm list , Radim Krcmar , "intel-sgx-kernel-dev@lists.01.org" , Paolo Bonzini To: Jarkko Sakkinen , "Huang, Kai" Return-path: Received: from mga05.intel.com ([192.55.52.43]:11610 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752643AbdFMUNF (ORCPT ); Tue, 13 Jun 2017 16:13:05 -0400 In-Reply-To: <20170613190550.2yxdpvcgeddyx3lv@intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On Tue, 2017-06-13 at 22:05 +0300, Jarkko Sakkinen wrote: > On Tue, Jun 13, 2017 at 09:57:18PM +0300, Jarkko Sakkinen wrote: > > > > On Mon, Jun 12, 2017 at 09:53:41PM +1200, Huang, Kai wrote: > > > > > > > > > > > > > > > > > This is simple, we simply won't allow guest to choose its own > > > > > IA32_SGXLEPUBKEYHASHn by specifying 'lehash' value in Qemu parameter > > > > > when > > > > > creating the guest. > > > > Why not? You could have virtual MSRs and ask host LE to generate token > > > > if they match to modulus. > > > The guest has its own LE running inside, and guest's LE will generate > > > token > > > for enclaves in guest. The host will not generate token for guest in any > > > circumstances, because this is totally guest's behavior. > > Why can't host LE generate the token without guest knowning it and > > supply it with EINIT? > > > > > > > > > > > Seriously sounds like a stupid constraint or I'm not getting something > > > > (which also might be the case). If you anyway trap EINIT, you could > > > > create a special case for guest LE. > > > This is not constraint, but KVM has to emulate hardware correctly. For > > > this > > > part please see my explanation above. > > I'm being now totally honest to your: your explanation makes absolutely > > zero sense to me. You don't need a 1000+ words to explain the scenarios > > where "host as a delegate LE" approach would go wrong. > > > > Please just pinpoint the scenarios where it goes wrong. I'll ignore > > the text below. > > > > /Jarkko > When I've been reading this discussion the biggest lesson for me has > been that this is a new argument for having in-kernel LE in addition > to what Andy has stated before: the MSRs *never* need to be updated on > behalf of the guest. > > /Jarkko The MSRs need to be written to run a LE in the guest, EINITTOKEN can't be used to EINIT an enclave that is requesting access to the EINITTOKENKEY, i.e. a LE. Preventing the guest from running its own LE is not an option, as the owner of the LE, e.g. guest kernel or userspace daemon, will likely disable SGX if its LE fails to run (including any ECALLS into the LE).  Allowing a guest to run a LE doesn't mean the host can't ignore/discard the guest's EINITTOKENs, assuming the host traps EINIT.