Virtualization is a pretty revolutionary idea, adding a layer of software to help us solve other problems in IT. From a risk perspective, though, it adds more things to track. This isn’t to say that ESXi is insecure – far from it. ESXi is the most secure hypervisor around (our Common Criteria certifications help demonstrate this, for example, as well as our outstanding record for fixing & disclosing issues). At VMware we’re honest about risk because we want our customers to be secure. When an application has a secret, like an encryption key or personally identifying information (PII), we must point out that the secret is visible to a lot of layers. First, it’s stored in system memory and in the CPUs. Second, the hypervisor can see it. Third, the guest OS can see it. And last, of course, the application.
What if there were a way to eliminate the guest OS and the hypervisor from the risk equation, though? As it turns out that’s what Intel’s Software Guard Extensions (SGX) strive to do. SGX allows an application to “conspire” with the CPU to keep secrets from the guest OS and the hypervisor, thereby reducing risk. Some applications are starting to explore this functionality, and in vSphere 7 we expose it to VMs running virtual hardware version 17. We call it “vSGX.”
When you’re running vSphere 7 on hardware that has SGX capabilities you can enable vSGX as part of the VM hardware configuration:
Sounds great, right? It’s a very interesting concept, using hardware to help keep secrets. However, a wise person once said that there isn’t such a thing as a free lunch. There’s always a catch. In this case, there are a few.
First, you need a CPU that supports SGX. These will be Intel CPUs — AMD has a different approach called Secure Encrypted Virtualization (SEV). As of this writing there aren’t many Intel server-class CPUs that support SGX, and they’re all single socket.
Second, there are some operational considerations. When you keep secrets from the hypervisor then the hypervisor can’t help you with vMotion, for instance. Or Fault Tolerance. You can’t suspend and resume or take snapshots because the hypervisor can’t copy memory to disk. Some of the Carbon Black Workload guest integrity checks can’t work, either.
You might think you can live without these things, but how will you patch your environment if you can’t use vMotion? What about DRS? These are fundamental things you’re denying yourself. SGX helps us add security, but security is a lot more than just one feature. Information security professionals think about security in terms of the CIA triad: confidentiality, integrity, and availability. While SGX might increase confidentiality it may do so at the expense of integrity and availability if an application isn’t designed properly.
Hardware-assisted secure enclaves are very interesting, and just the tip of the iceberg when it comes to what CPU hardware can help us with. Like many situations in IT, though, it’s best when their use is a collaboration between BOTH the infrastructure and the applications.
We are excited about vSphere 7 and what it means for our customers and the future. Watch the vSphere 7 Launch Event replay, an event designed for vSphere Admins, hosted by theCUBE. We will continue posting new technical and product information about vSphere 7 and vSphere with Kubernetes Monday through Thursdays into May 2020. Join us by following the blog directly using the RSS feed, on Facebook, and on Twitter. Thank you, and please stay safe.
