From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Christopherson, Sean J" Subject: RE: [intel-sgx-kernel-dev] [PATCH 08/10] kvm: vmx: add guest's IA32_SGXLEPUBKEYHASHn runtime switch support Date: Wed, 14 Jun 2017 15:11:34 +0000 Message-ID: <37306EFA9975BE469F115FDE982C075BC6115D3F@ORSMSX108.amr.corp.intel.com> References: <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> <1497384784.23465.29.camel@intel.com> <20170614093741.rll26hq72hrt4tou@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Cc: "Huang, Kai" , kvm list , Radim Krcmar , "intel-sgx-kernel-dev@lists.01.org" , Paolo Bonzini To: 'Jarkko Sakkinen' Return-path: Received: from mga11.intel.com ([192.55.52.93]:23413 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751990AbdFNPLg (ORCPT ); Wed, 14 Jun 2017 11:11:36 -0400 In-Reply-To: <20170614093741.rll26hq72hrt4tou@intel.com> Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: Jarkko Sakkinen 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