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
