Linux Kernel 4.14/4.15 and AMD’s SEV memory module

In my previous post I made brief mention of some new features in the 4.15 (well, technically, 4.14) Linux kernel, supporting encrypted volatile memory (RAM). Apart from a brief awareness of industry initiatives in this area, I hadn’t closely followed this development and so decided to take a look and write up some findings in this blog post.

So what are we talking about here? What is this capability, and what does it deliver to IT in general and specifically, system security? The feature we are talking about is AMD’s Secure Encrypted Virtualisation (SEV).

One of the murmurings in the industry some years ago was a desire to address the fundamental weakness in virtualisation. This weakness stems from the architecture of virtualisation and the hypervisors that deliver it: if you can compromise the hypervisor or Virtual Machine Monitor (VMM), then it would naturally follow that you could compromise VMs operating atop of that hypervisor. In particular, if you could compromise the host you could compromise the pages within RAM that VMs would use, as they are stored in plaintext. This could be used, for example, to recover credentials or other sensitive data, in order to mount a further attack.

This of itself does not sound like a significant problem–with good patching and system security management, we should be OK? Winding forward the clock to today, the situation could not be more different.

Hypervisors are the norm and multi-tenanted solutions are common place. For some customers the notion of such large amounts of data mixing in memory, reliant on processor microcode to separate potentially different security domains, is troublesome. The effect of consolidating many and varied workloads onto hypervisors, particularly in data centres, also means hypervisors have magnified to a significant extent the return on investment to a would-be attacker seeking to compromise a hypervisor.

SEV attempts to solve this problem by encrypting the memory, used by a VM and managed by the VMM, by wrapping up pages using an individual encryption key. To prevent the key itself being compromised, AMD’s design turns to hardware in an attempt to isolate the key within a hardware security module on the motherboard. With a virtualisation platform that supports SEV, the encryption capability of the module can be enabled and used to, in effect, isolate VM’s from the VMM, from physical attack and from one another. By design, the host environment will be unable to decrypt pages from a VM.

The concept is an interesting one: end-users of multi-tenanted architectures can have increased trust in the capabilities of the platform, and have less concern for potentially cross-boundary compromises in that environment.

However, as with many of the best-intentioned security features, SEV has been beset with difficulties.

Fraunhofer researchers were able to demonstrate, via the SEVered attack, that a malicious hypervisor could indeed extract plaintext memory from SEV-encrypted VMs, using a re-mapping technique executed on the hypervisor while communicating with a target service such as OpenSSH.

Extraction rates varied from 41.6KB/sec to 79.4KB/sec for various software targets. All that is needed is a communicating service in the target VM. The researchers were able to do this by exploiting a design flaw in the SEV processor, which, while it does ensure confidentiality does not ensure integrity of the data it handles.

So in summary the new features that the Linux kernel supports are helpful, and certainly increase the resistance to the system to attack. Added to that is AMD’s assertion that using a SEVered attack is difficult attack to execute, which has some merit (Fraunhofer’s attack required a low-level modification to the hypervisor).

However it does illustrate that the SEV capabilities in the latest releases of the kernel may not be as exciting as they might first seem.

The question therefore is SEV a beneficial feature in the Linux kernel from a security standpoint, and should it be used?

There have been many security concepts proposed over the years that have promised to deliver game-changing capability but have been later shown to be very easy to bypass, for example Microsoft EMET.

SEV will deliver a degree of security both between VMs, between VMs and the VMM, and against physical recovery (e.g. cold-temperature RAM recovery), and so it will raise the bar and close off a class of (in comparison) trivial attack vectors. So, generally, it is beneficial.

On the question of whether it should be used, it is more complex. This is primarily going to rest on a business impact assessment. SEV will have a performance overhead. You’ll also need a VMM that can support SEV, which may mean more cost. Finally, the threat environment should be considered: if the hypervisor operates in a trusted environment on trusted data, then the benefits are only really against physical data recovery methods.