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: Fri, 16 Jun 2017 15:46:31 +1200 Message-ID: <91b9e29f-fc15-7524-3740-4417d3a1dd8f@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> <92f3b0cc-1f04-d8a5-9e86-0417f75f8ed9@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 mga01.intel.com ([192.55.52.88]:17141 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750792AbdFPDq6 (ORCPT ); Thu, 15 Jun 2017 23:46:58 -0400 In-Reply-To: Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: On 6/13/2017 11:00 AM, Andy Lutomirski wrote: > On Mon, Jun 12, 2017 at 3:08 PM, Huang, Kai wrote: >> >> 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. >> > > The whole point is that I don't know. But here are two types of > restriction I can imagine demand for: > > 1. Only a particular approved provisioning enclave may run (be it > Intel's or otherwise -- with a non-Intel LE, I think you can launch a > non-Intel provisioning enclave). This would be done to restrict what > types of remote attestation can be done. (Intel supplies a remote > attestation service that uses some contractual policy that I don't > know. Maybe a system owner wants a different policy applied to ISVs.) > Imposing this policy on guests more or less requires filtering EINIT. Hi Andy, Sorry for late reply. What is the issue if host and guest run provisioning enclave from different vendor, for example, host runs intel's provisioning enclave, and guest runs other vendor's provisioning enclave? Or different guests run provisioning enclaves from different vendors? One reason I am asking is that, on Xen (where we don't have concept of *host*), it's likely that we won't apply any policy at Xen hypervisor at all, and guests will be able to run any enclave from any signer as their wish. Sorry that I don't understand (or kind of forgot) the issues here. > > 2. For kiosk-ish or single-purpose applications, I can imagine that > you would want to allow a specific list of enclave signers or even > enclave hashes. Maybe you would allow exactly one enclave hash. You > could kludge this up with a restrictive LE policy, but you could also > do it for real by implementing the specific restriction in the kernel. > Then you'd want to impose it on the guest, and you'd do it by > filtering EINIT. Assuming the enclave hash means measurement of enclave, and assuming we have a policy that we only allow enclave from one signer to run, would you also elaborate the issue that, if host and guest run enclaves from different signer? If host has such policy, and we are allowing creating guests on such host, I think that typically we will have the same policy in the guest (vetted by guest's kernel). The owner of that host should be aware of the risk (if there's any) by creating guest and run enclave inside it. Thanks, -Kai > > For the time being, I don't expect either policy to be implemented > right away, but I bet that something like this will eventually happen. >