From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarkko Sakkinen Subject: Re: [intel-sgx-kernel-dev] [PATCH 08/10] kvm: vmx: add guest's IA32_SGXLEPUBKEYHASHn runtime switch support Date: Wed, 14 Jun 2017 19:03:28 +0200 Message-ID: <20170614170328.aalayx7mozukyqdg@intel.com> References: <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> <37306EFA9975BE469F115FDE982C075BC6115D3F@ORSMSX108.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Huang, Kai" , kvm list , Radim Krcmar , "intel-sgx-kernel-dev@lists.01.org" , Paolo Bonzini To: "Christopherson, Sean J" Return-path: Received: from mga06.intel.com ([134.134.136.31]:3788 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751902AbdFNRDd (ORCPT ); Wed, 14 Jun 2017 13:03:33 -0400 Content-Disposition: inline In-Reply-To: <37306EFA9975BE469F115FDE982C075BC6115D3F@ORSMSX108.amr.corp.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jun 14, 2017 at 03:11:34PM +0000, Christopherson, Sean J wrote: > 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." Thanks. I wonder by the naming is ambiguous (the value is exactly the same as the value of ATTRIBUTES.EINITTOKENKEY but the name is different) but there it is. > > 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". Agreed! That was a harsh overstatement. I think that in this kind of stuff the accurancy still would make sense when cryptography is involved. I'll make updates to intel_sgx.rst. It's good to have it documented when virtualization stuff is upstreamed. /Jarkko