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

[Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>]

On Tue, Jun 13, 2017 at 01:13:04PM -0700, Sean Christopherson wrote:
 
> 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.

[I started one week leave today but will peek MLs seldomly so except
some delay in my follow up responses]

Please, lets not use the term ECALL in these discussions. It's neither
hardware nor kernel specific concept. It's abstraction that exists only
in the Intel SDK. I have neither ECALLs nor OCALLs in my LE for example.
There are enough moving parts without such abstraction.

I'm looking at the section "EINIT - Initialize an Enclave for Execution"
from the SDM. I'm not seeing a branch in the pseudo code that checks for
ATTRIBUTES.EINITTOKENKEY.

39.1.4 states that "Only Launch Enclaves are allowed to launch without a
valid token." I'm not sure what I should deduce from that because that
statement is *incorrect*. If you control the MSRs, you can launch
anything you want to launch. I guess we should make a bug report of this
section as it's complete nonsense?

The table 41-56 does not show any key material bound to key hash defined
in the MSRs.

Instead of teaching me stuff that I already know I would just like to
get pinpointed where is the "side-effect" that makes the constraint that
you are claiming. I can then update the documentation so that we don't
have to go through this discussion anymore :-)

/Jarkko