Re: [intel-sgx-kernel-dev] [PATCH 08/10] kvm: vmx: add guest's IA32_SGXLEPUBKEYHASHn runtime switch support

From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	"Huang, Kai" <kai.huang@linux.intel.com>
Cc: kvm list <kvm@vger.kernel.org>, Radim Krcmar <rkrcmar@redhat.com>,
	"intel-sgx-kernel-dev@lists.01.org"
	<intel-sgx-kernel-dev@lists.01.org>,
	Paolo Bonzini <pbonzini@redhat.com>
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	[thread overview]
Message-ID: <1497384784.23465.29.camel@intel.com> (raw)
In-Reply-To: <20170613190550.2yxdpvcgeddyx3lv@intel.com>

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.