From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [intel-sgx-kernel-dev] [PATCH 08/10] kvm: vmx: add guest's IA32_SGXLEPUBKEYHASHn runtime switch support Date: Mon, 12 Jun 2017 09:24:27 -0700 Message-ID: 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" Cc: Jarkko Sakkinen , 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 mail.kernel.org ([198.145.29.99]:39112 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752366AbdFLQY4 (ORCPT ); Mon, 12 Jun 2017 12:24:56 -0400 Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com [209.85.213.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EB37923A07 for ; Mon, 12 Jun 2017 16:24:49 +0000 (UTC) Received: by mail-vk0-f52.google.com with SMTP id y70so11720606vky.3 for ; Mon, 12 Jun 2017 09:24:49 -0700 (PDT) In-Reply-To: <3bbe95fe-bb97-d430-e9d3-d4edcb381f46@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. 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. 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. 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. 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.