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 11:37:41 +0200 Message-ID: <20170614093741.rll26hq72hrt4tou@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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "Huang, Kai" , kvm list , Radim Krcmar , "intel-sgx-kernel-dev@lists.01.org" , Paolo Bonzini To: Sean Christopherson Return-path: Received: from mga07.intel.com ([134.134.136.100]:63469 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751700AbdFNJhr (ORCPT ); Wed, 14 Jun 2017 05:37:47 -0400 Content-Disposition: inline In-Reply-To: <1497384784.23465.29.camel@intel.com> Sender: kvm-owner@vger.kernel.org List-ID: 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