From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Huang, Kai" Subject: Re: [intel-sgx-kernel-dev] [PATCH 08/10] kvm: vmx: add guest's IA32_SGXLEPUBKEYHASHn runtime switch support Date: Tue, 13 Jun 2017 10:08:01 +1200 Message-ID: <92f3b0cc-1f04-d8a5-9e86-0417f75f8ed9@linux.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> <20170612083658.vrrcr6dq6axiovse@intel.com> <3bbe95fe-bb97-d430-e9d3-d4edcb381f46@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jarkko Sakkinen , Kai Huang , Paolo Bonzini , Radim Krcmar , kvm list , "intel-sgx-kernel-dev@lists.01.org" , haim.cohen@intel.com To: Andy Lutomirski Return-path: Received: from mga07.intel.com ([134.134.136.100]:41274 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752430AbdFLWII (ORCPT ); Mon, 12 Jun 2017 18:08:08 -0400 In-Reply-To: Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: On 6/13/2017 4:24 AM, Andy Lutomirski wrote: > On Mon, Jun 12, 2017 at 2:53 AM, Huang, Kai wrote: > \ >>> >>>>> 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. >> >> >> The guest has its own LE running inside, and guest's LE will generate token >> for enclaves in guest. The host will not generate token for guest in any >> circumstances, because this is totally guest's behavior. >> >> Virtualization is only about to emulate hardware's behavior, but not to >> assume, or depend on, or change guest's SW behavior. We are not trying to >> make sure EINIT will run successfully in guest, instead, we are trying to >> make sure EINIT will be just the same behavior as it runs on physical >> machine -- either success or failure, according to guest's sigstruct and >> token. > > I disagree. Virtualization can do whatever it wants, but a pretty > strong constraint is that the guest should be at least reasonably > function. Virtualization only can do whatever it wants on the part that it can trap and emulate, and such *whatever* should not break HW behavior presented to guest. This is fundamental thing for virtualization. I don't know whether there are some *minor* case that the HW behavior emulation is not fully respected but I believe, if they exist, those cases are extremely rare, and we certainly have a good reason why such cases are OK. Anyway I'll leave this part to KVM maintainers. Paolo, Radim, Sorry this thread is a little bit long till now. Can you comments on this? A Windows guest, for example, shouldn't BSOD. But the host > most certainly can restrict what the guest can do. If a guest is > given pass-through access to a graphics card, the host is well within > its rights to impose thermal policy, prevent reflashing, etc. You need to see whether those policies are provided by PCIE configration space or by device's registers. If policies are implemented via PCIE configuration space (which is trapped and emulated by VMM/Qemu), you certainly can apply restrict on it by emulating PCIE configuration space access. But if those policies are done by device registers, which driver will control totally, it's totally up to driver and host cannot apply any policies. You can choose to or not to pass through device's specific BARs (ex, you cannot passthrough the BARs contains MSI), but once the BARs are passthroughed to guest, you cannot control guest's behavior. > Similarly, if a guest is given access to SGX, the host can and should > impose required policy on the guest. If this means that an EINIT that > would have succeeded at host CPL 0 fails in the guest, so be it. This is completely different. And I disagree. If EINIT can run at host CPL 0, it can be run in guest's CPL 0 as well. Unless hardware doesn't support this, in which case we even cannot support SGX virtualization. The exception is, if HW provides, for example, some specific capability bits that can be used to control whether EINIT can be run in CPL 0 or not, and hypervisor is able to trap those bits, then hypervisor can manipulate those bits to make guest think HW doesn't allow EINIT to run in CPL 0, in which case it is quite reasonable in guest EINIT cannot run in CPL 0 (because it is HW behavior). > > Of course, there isn't much in the way of host policy right now, so > this may not require any particular action until interesting host > policy shows up. > >> This is not constraint, but KVM has to emulate hardware correctly. For this >> part please see my explanation above. >> >> And let me explain the purpose of trapping EINIT again here. >> >> When guest is about to run EINIT, if guest's SHA256(sigstruct->modulus) >> matches guest's virtual IA32_SGXLEPUBKEYHASHn (and if others are correctly >> populated in sigstruct and token as well), KVM needs to make sure that EINIT >> will run successfully in guest, even physical IA32_SGXLEPUBKEYHASHn are not >> equal to guest's virtual MSRs at this particular time. > > True, so long as it doesn't contradict host policy to do so. > >> This is because given >> the same condition, the EINIT will run successfully on physical machine. KVM >> needs to emulate the right HW behavior. > > No. The host needs to do this because KVM needs to work and be > useful, not because KVM needs to precisely match CPU behavior as seen > by VMX root. If we need to break HW behavior to make SGX useful. The maintainer may choose not to support SGX virtualization, as from HW this feature simply cannot be virtualized. Anyway I'll leave this to KVM maintainers to determine. > > To avoid confusion, I don't believe I've ever said that guests should > be restricted in which LEs they can use. The types of restrictions > I'm talking about are that, if the host prevents user code from > running, say, a provisioning enclave that isn't whitelisted, then the > guest should have the same restriction applied. This type of > restriction *can't* be usefully done by restricting acceptable MSR > values, but it's trivial by trapping EINIT. OK. Sorry I didn't get your point before. I thought it was about restrict LE. I don't know whether SGX driver will have restrict on running provisioning enclave. In my understanding provisioning enclave is always from Intel. However I am not expert here and probably be wrong. Can you point out *exactly* what restricts in host must/should be applied to guest so that Jarkko can know whether he will support those restricts or not? Otherwise I don't think we even need to talk about this topic at current stage. Thanks, -Kai >