VMware vSphere Now Supports AMD EPYC’s ‘Powerful’ SEV Features

The latest version of vSphere supports the AMD EPYC processors’ Secure Encrypted Virtualization features, which provide full in-memory encryption for hypervisors and virtual machines, giving the chipmaker a one-up over rival Intel in the virtualization market.

VMware vSphere now supports “powerful” silicon-level security features enabled by AMD’s second-generation EPYC processors that protects the hypervisor and virtual machines from each other using full in-memory encryption, giving AMD a one-up over rival Intel in the virtualization market.

Support for AMD EPYC’s Secure Encrypted Virtualization (SEV) and Secure Encrypted Virtualization-Encrypted State (SEV-ES) was announced Wednesday as part of the VMware vSphere 7 Update 1 rollout that coincided with a wider launch of new releases for several VMware products the day before.

[Related: AMD's Xbox, PlayStation Work Led To A Big Security Feature In EPYC]

VMware’s support for AMD’s SEV features comes as the chipmaker is gaining data center market share against Intel, which has fallen behind AMD in using next-generation manufacturing processes and is turning to new design methodologies to drive more performance and new features. But AMD’s traction in the virtualization market hasn’t been completely smooth, with VMware deciding earlier this year to essentially the double the software licensing costs for AMD’s higher-core processors.

In a blog post Wednesday, Bob Plankers, a technical marketing architect at VMware, said vSphere 7 is the first hypervisor to provide support for both SEV and SEV-ES, offering users advanced security on top of ESXi software-based layers of isolation that separate the hypervisor from guest VMs.

The difference, he said, is that VMware’s software-based isolation doesn’t address security issues at the hardware level, including the CPU, memory controllers and other PCIe bus controllers.

AMD’s SEV and SEV-ES features are made possible by an Arm-based secure co-processor inside EPYC processors that generates and manages encryption keys to provide encryption to both the hypervisor and guest VMs, preventing each party from accessing their respective keys.

Plankers singled out SEV-ES as something VMware customers should embrace and said it offers a “very powerful protection against entire classes of vulnerabilities, both in hardware and in the hypervisor.” This form of protection takes things a step further than SEV by encrypting all the contents of the CPU registers, preventing any leakage of information from VMs to the hypervisor.

“A compromised hypervisor could read or modify that register data, either to steal the data itself, steal things like encryption keys that are held in CPU registers (to decrypt a disk, for example), or to alter the behavior of the VM itself,” Plankers wrote in the blog post. “None of those things are good. With SEV-ES, the hypervisor does not have access to the encryption keys for a guest unless the guest explicitly allows it, greatly reducing the attack surface.”

One of the bonuses of AMD’s SEV and SEV-ES features is that they don’t require modifications to applications to work, according to Plankers. The features are also flexible and can be enabled and disabled for any workload without any consequences.

“This technology isn’t all or nothing, even on a single host,” he said. “You can enable it for certain workloads, leave it disabled for others, and they all coexist peacefully. That flexibility means that enabling and deploying this technology can be done at your own pace.”

One downside, however, is that cutting off the hypervisor’s access to the VM’s memory does prevent certain vSphere features, like vMotion, memory snapshots, hot add of devices, suspend and resume, Fault Tolerance and hot clones, Plankers said. But losing vMotion may not be an issue because good design can make applications and services resilient to maintenance operations, he added, plus vSphere with Tanzu doesn’t use the vMotion function for Kubernetes workloads.

To take advantage of AMD’s SEV and SEV-ES features in vSphere, users need to use the chipmaker’s second-generation of EPYC processors that launched last year, according to Plankers. They also require support from the guest operating system, which currently includes some Linux distributions and kernels.

“AMD has demonstrated considerable thoughtfulness towards consumers with how they’ve designed these features, and their ideals mesh well with our work to make security extremely easy to use inside vSphere,” Plankers said. “It’s always nice to have these types of tools in our collective security toolbox, helping to reduce risk, and we at VMware are proud to lead the industry in championing them.”

While AMD’s SEV features are available across its entire AMD EPYC stack, Intel’s equivalent technology, Intel Software Guard Extensions (SGX), isn’t available yet in most Xeon processors, limiting the options for vSphere users who want to take advantage of Intel SGX. It’s one reason why Google Cloud decided to use SEV for its new Confidential Virtual Machines product.

Worth Davis, president of the solution provider business for Computex Technology Solutions, a Houston, Texas-based VMware partner, welcomed AMD’s increasing competitiveness and told CRN that silicon-level vulnerabilities like Meltdown and Spectre that emerged in 2018 have shown the need to have more hardware-based security in processors.

“I think these are important features in systems today since Spectre and other variant issues that cropped up a few years ago,” he said in an email. “Price and Performance will always be the driving factors in platform consideration, but security definitely has a weight and requirement as well. It’s good to see competition overall as it benefits all consumers of data center-grade processing.”

In an interview with CRN last year, top AMD executive Forrest Norrod predicted that SEV will eventually become a must-have feature in the near future.

“I think that it in three to four years, it will be ridiculous to even consider deploying a [virtual machine] in the cloud if you can‘t control and isolate that thing cryptographically from the cloud provider,” he said. “I think that your risk management guys [will say], ‘What are you talking about?’”