RE: [intel-sgx-kernel-dev] [PATCH 08/10] kvm: vmx: add guest's IA32_SGXLEPUBKEYHASHn runtime switch support

From: "Christopherson, Sean J" <sean.j.christopherson@intel.com>
To: "Christopherson, Sean J" <sean.j.christopherson@intel.com>,
	"'Andy Lutomirski'" <luto@kernel.org>,
	"Huang, Kai" <kai.huang@linux.intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	"Cohen, Haim" <haim.cohen@intel.com>,
	"intel-sgx-kernel-dev@lists.01.org"
	<intel-sgx-kernel-dev@lists.01.org>,
	kvm list <kvm@vger.kernel.org>, Radim Krcmar <rkrcmar@redhat.com>
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	[thread overview]
Message-ID: <37306EFA9975BE469F115FDE982C075B9B70691D@ORSMSX108.amr.corp.intel.com> (raw)
In-Reply-To: <37306EFA9975BE469F115FDE982C075B9B706869@ORSMSX108.amr.corp.intel.com>

Christopherson, Sean J <sean.j.christopherson@intel.com> wrote:
> Andy Lutomirski <luto@kernel.org> wrote:
> > On Thu, May 11, 2017 at 9:56 PM, Huang, Kai <kai.huang@linux.intel.com>
> > >> [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.