From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Christopherson, Sean J" Subject: RE: [intel-sgx-kernel-dev] [PATCH 08/10] kvm: vmx: add guest's IA32_SGXLEPUBKEYHASHn runtime switch support Date: Fri, 12 May 2017 20:50:23 +0000 Message-ID: <37306EFA9975BE469F115FDE982C075B9B70691D@ORSMSX108.amr.corp.intel.com> References: <20170508052434.3627-1-kai.huang@linux.intel.com> <20170508052434.3627-9-kai.huang@linux.intel.com> <58dcdb2d-6894-b0a3-8d6f-2ab752fd6d22@linux.intel.com> <6ab7ec4e-e0fa-af47-11b2-f26edcb088fb@linux.intel.com> <37306EFA9975BE469F115FDE982C075B9B706869@ORSMSX108.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Cc: Paolo Bonzini , "Cohen, Haim" , "intel-sgx-kernel-dev@lists.01.org" , kvm list , Radim Krcmar To: "Christopherson, Sean J" , "'Andy Lutomirski'" , "Huang, Kai" Return-path: Received: from mga05.intel.com ([192.55.52.43]:9779 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757872AbdELUuY (ORCPT ); Fri, 12 May 2017 16:50:24 -0400 In-Reply-To: <37306EFA9975BE469F115FDE982C075B9B706869@ORSMSX108.amr.corp.intel.com> Content-Language: en-US Sender: kvm-owner@vger.kernel.org List-ID: Christopherson, Sean J wrote: > Andy Lutomirski wrote: > > On Thu, May 11, 2017 at 9:56 PM, Huang, Kai > > >> [1] Guests that steal sealed data from each other or from the host can > > >> manipulate that data without compromising the hypervisor by simply > > >> loading the same enclave that its rightful owner would use. If you're > > >> trying to use SGX to protect your crypto credentials so that, if > > >> stolen, they can't be used outside the guest, I would consider this to > > >> be a major flaw. It breaks the security model in a multi-tenant cloud > > >> situation. I've complained about it before. > > >> > > > > > > Looks potentially only guest's IA32_SGXLEPUBKEYHASHn may be leaked? In > > > this case even it is leaked looks we cannot dig anything out just the > > > hash value? > > > > Not sure what you mean. Are you asking about the lack of guest > > personalization? > > > > Concretely, imagine I write an enclave that seals my TLS client > > certificate's private key and offers an API to sign TLS certificate > > requests with it. This way, if my system is compromised, an attacker > > can use the certificate only so long as they have access to my > > machine. If I kick them out or if they merely get the ability to read > > the sealed data but not to execute code, the private key should still > > be safe. But, if this system is a VM guest, the attacker could run > > the exact same enclave on another guest on the same physical CPU and > > sign using my key. Whoops! > > I know this issue has been raised internally as well, but I don't know > the status of the situation. I'll follow up and provide any information > I can. So, the key players are well aware of the value added by per-VM keys, but, ultimately, shipping this feature is dependent on having strong requests from customers.