Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote:
> 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.
(* if controlled ATTRIBUTES are set, SIGSTRUCT must be signed using an authorized key *)
CONTROLLED_ATTRIBUTES <- 0000000000000020H;
IF (((DS:RCX.ATTRIBUTES & CONTROLLED_ATTRIBUTES) != 0) and (TMP_MRSIGNER != IA32_SGXLEPUBKEYHASH))
RFLAG.ZF <- 1;
RAX <- SGX_INVALID_ATTRIBUTE;
GOTO EXIT;
FI;
Bit 5, i.e. 20H, corresponds to the EINITTOKENKEY. This is also covered in the
text description under Intel SGX Launch Control Configuration - "The hash of the
public key used to sign the SIGSTRUCT of the Launch Enclave must equal the value
in the IA32_SGXLEPUBKEYHASH MSRs."
> 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?
I wouldn't call it complete nonsense, there are far more egregious ambiguities
in the SDM. If you read the statement in the context of someone learning about
SGX, it makes perfect sense: if it's not a launch enclave, it needs a token.
Sure, rewording the statement to something like "Only enclaves whose public key
hash equals the value in the IA32_SGXLEPUBKEYHASH MSRs are allowed to launch
without a token." is technically more accurate, but I wouldn't describe the
current wording as "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
