Introduction
As all of you probably know by now, the last couple of years presented us with an increasing number and scale of attacks caused by the hardware vulnerabilities. The most infamous are Meltdown and Spectre vulnerabilities detected in Intel processors.
What troubles people the most is that most of these vulnerabilities are in the fundamental hardware layer. Which means basically two things. One, such vulnerability is one hell of a headache to get rid of. Second, system updates, this universal panacea, can cause, in these particular cases, side effects so severe that the user would wish to roll back the update.
For example, some of you remember the well-known problem with the performance of ESXi after applying the security fix. At the time, OS vendors have released respective updates, and VMware has released a patch that was supposed to deal with the vulnerability. This plan backfired when the patch did not work, was abandoned, and the time spent releasing a new one cost everybody, including users and admins.
What is What
With those cases in mind, it makes no surprise to find out that processor manufacturers and virtualization platforms vendors have been working on the problem for a while now.
AMD, as you can guess, is no exception. The company has its own strategy regarding physical CPU security:
- Secure Encrypted Virtualization (SEV) – their first try that has been announced in 2016. It separates virtual machines from the hypervisor to protect them if the latter is ever compromised. So, if the hypervisor tries to read the guest OS information, all it would get would be encrypted data.
- SEV-ES (Encrypted State) – next run, announced in 2017. It is supposed to complete guest OS protection by encrypting all CPU registers content. That way, the CPU registers actively used by a virtual machine are out of the hypervisor’s sight.
- SEV-SNP (Secure Nested Paging) – finally, the latest generation, released this very year. It brings to the table hardware security functions to watch over the guest OS RAM integrity. This technology serves as a countermeasure against attacks such as data replay, memory remapping, etc (more here and below).
In VMware vSphere 7 Update 1, there’s a new SEV-ES (Encrypted State) technology support, which allows increasing your chances against any potential vulnerability connected with data access inside the processor, should it ever arise. It requires AMD EPYX 7xx2 CPU to work (or later series, of course), and VM Virtual Hardware 18 (conveniently presented in VMware vSphere 7 Update 1).
For starters, VMware has already got guest OS RAM and data security employed for a while now (that’s without mentioning Guest OS security mechanisms), but, naturally, these measures aren’t 100% reliable. See, the most common source of a threat is the hypervisor itself, and simultaneously it’s a key component of any virtualization platform. If it’s compromised, there’s hardly anything at all you can do to fix that.
Hence, to avoid any mishaps, the only optional choice is isolating the hypervisor from VMs on the hardware level as much as possible. That’s called a Trusted Execution Environment (TEE).
The secret to the AMD approach is an additional Secure Processor, a small coprocessor, integrated into the primary CPU. This thing is a baseline of security and is in charge of encryption operations, including SEV-ES.
The first EPYC CPU generation was able to handle no more than 15 encryption keys. Now it’s over 500.
One of those goes to the hypervisor itself; the rest is for the guest OSes.
Why would anyone even bother with guest systems CPU registers security, you may ask? Well, the way it goes, when the VM switches CPUs, the hypervisor receives all its resources along with its contents. Now, those contents can store a massive hunk of information, potentially attractive to any attackers: passwords, encryption keys, etc.
The keys work in a very simple way:
- The guest OS sends a request to CPU (SEV must be supported, naturally) for the RAM encryption key;
- The SEV-ES expands it on the CPU registers;
- Voila, the guest OS can employ memory and registers without letting the hypervisor or the other VMs (that are also isolated inside VMX processes), reading its contents.
Of course, the guest OS has to have SEV-ES support employed as well (which is why it never hurts to get through the accompanying documentation).
The only huge disadvantage, in this case, is that once you have decided to use SEV-ES technology, it’s a no-no for the rest: vMotion, Memory Snapshots, Guest Integrity, Hot Add, Suspend & Resume, Fault Tolerance, or Hot Cloning are out of the table now. Why? For these solutions to work, the hypervisor will need direct access to guest OS RAM.
At the same time, I cannot avoid mentioning that this limitation isn’t from AMD (which claims that SEV-ES is perfectly compatible with live migration, etc), but an implementation restriction from VMware.
The inability of applying all those services is why in any work environment, the SEV-ES technology would be used only to the systems that need the highest security level.
On the other hand, however, the recent vSphere with Tanzu solution doesn’t even use vMotion for the machines with virtualized app containers: they are just shut down on one host and started on another one. As you can see for yourself, there’s a future for SEV-ES here.
You can also work with the SEV-ES support for VMs in a batch mode, applying it for the thousands of VMs via PowerCli interface (Tanzu containers users, take a note). Nevertheless, since the official VMware information on the SEV-ES cmdlets is yet to be released, all we have to do is wait.
Not so long ago, by the way, VMware has released an interesting video, covering the first implementation of the SEV-ES in the VMware vSphere 7 Update 1:
To Sum Up
Admittedly, such technologies as Secure Encrypted Virtualization aren’t widely employed due to their numerous restrictions. Do keep in mind, though, that these are only baby steps in that direction. Its development will eventually bring everything the users need right now (including AMD SEV-SNP support), thereby limiting the area of potential attacks.
