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