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: Mon, 12 Jun 2017 11:36:58 +0300 Message-ID: <20170612083658.vrrcr6dq6axiovse@intel.com> References: <6ab7ec4e-e0fa-af47-11b2-f26edcb088fb@linux.intel.com> <596dc1ad-eac7-798d-72e5-665eb7f3f2e4@linux.intel.com> <0b4697b9-0976-c8ad-e26f-4ff683318486@linux.intel.com> <20170608123101.47pgsaovkgtdxaw4@intel.com> <46bdaa22-8e7d-738f-9dd0-840fe3327506@linux.intel.com> <20170610122306.lfjshzepqxxyqj72@intel.com> <001ecd91-15e7-ef5a-097b-d57bc7784f47@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andy Lutomirski , Kai Huang , Paolo Bonzini , Radim Krcmar , kvm list , "intel-sgx-kernel-dev@lists.01.org" , haim.cohen@intel.com To: "Huang, Kai" Return-path: Received: from mga11.intel.com ([192.55.52.93]:38469 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751942AbdFLIhC (ORCPT ); Mon, 12 Jun 2017 04:37:02 -0400 Content-Disposition: inline In-Reply-To: <001ecd91-15e7-ef5a-097b-d57bc7784f47@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Jun 12, 2017 at 10:45:07AM +1200, Huang, Kai wrote: > > > But it may still be better if SGX driver can provide function like: > > > > > > int sgx_validate_sigstruct(struct sigstruct *sig); > > > > > > for KVM to call, in case driver is changed (ex, to only allows LEs from some > > > particular ones to run), but this is not necessary now. KVM changes can be > > > done later when driver make the changes. > > > > > > Andy, > > > > > > Am I understanding correctly? Does this make sense to you? > > > > > > Thanks, > > > -Kai > > > > Nope. I don't even understand the *beginnings* what that function would > > do. I don't understand what the validation means here and what VMM would > > do if that functions reports "success". > > The validation means either the sigstruct->modulus or > SHA256(sigstruct->modulus) should be in a 'approved white-list' maintained > by kernel (which I know doesn't exist now, but Andy some kind suggested we > may or should have, in the future I guess), otherwise the function returns > error to indicate the LE from guest is "unapproved by host kernel/driver". > > Andy, would you explain here? That can be considered but I still have zero idea what this function is and what its relation to whitelist would be. > > How that would work on a system where MSRs cannot be changed? > > This is simple, we simply won't allow guest to choose its own > IA32_SGXLEPUBKEYHASHn by specifying 'lehash' value in Qemu parameter when > creating the guest. Why not? You could have virtual MSRs and ask host LE to generate token if they match to modulus. > To elaborate, currently in my design Qemu has below new parameters to > support SGX: > > # qemu-system-x86_64 -sgx, epc=,lehash=,lewr > > The 'epc=' specifies guest's EPC size obviously, lehash specifies > guest's initial IA32_SGXLEPUBKEYHASHn (similar to the value configured in > BIOS for real machine), and 'lewr' specifies whether guest's > IA32_SGXLEPUBKEYHASHn can be changed by OS at runtime. The 'lehash' and > 'lewr' are optional. > > If MSRs cannot be changed on physical machine, then we will fail to create > guest if either 'lehash' or 'lewr' is specified when creating the guest. > > > > > In that kind of system the host OS must generate EINITTOKEN for the LE > > running on inside the guest and maintain completely virtualized MSR > > values for the guest. > > The host OS will not generate EINITTOKEN for guest in any circumstances, as > EINITTOKEN will always be from guest's EINIT instruction. KVM traps EINIT > from guest and gets both SIGSTRUCT and EINITTOKEN from the EINIT leaf, > update MSRs, and run EINIT on behalf of guest. Seriously sounds like a stupid constraint or I'm not getting something (which also might be the case). If you anyway trap EINIT, you could create a special case for guest LE. /Jarkko