AMD virty encryption not quite there, claim boffins
Don't put your VMs in a spook-controlled cloud
Updated A couple of German boffins have taken a good look at AMD's Secure Encrypted Virtualization (SEV), and don't like what they see.
As AMD's Brijesh Singh explained to the Linux driver project mailing list in April, SEV extends the AMD-V architecture when multiple VMs are running under a hypervisor: “SEV hardware tags all code and data with its VM ASID which indicates which VM the data originated from or is intended for. This tag is kept with the data at all times when inside the SOC, and prevents that data from being used by anyone other than the owner”.
In this paper at Arxiv, Felicitas Hetzelt and Robert Buhren of the Technical University of Berlin identify shortcomings in the architecture, including possible encryption bypass, information leakage, and memory replay attacks.
Hetzelt and Buhren tested the environment on a Linux machine running KVM/QEMU.
“The key idea of SEV is that guest memory is encrypted and the corresponding key is only accessed by the memory controller that handles the encryption and decryption transparently, thereby protecting against both a malicious hypervisor and physical attacks,” they write.
“This key will never be exposed to the hypervisor. Additionally AMD added a coprocessor to SEV-enabled CPUs … This coprocessor handles key management and is responsible for the initial encryption of the guest.”
Once it's loaded, SEV encrypts memory pages marked “private” with AES, using a guest-specific key.
The paper describes three possible attack vectors:
- General purpose registers offer potential vectors to expose confidential data, while the CPU is switching from guest mode to host mode;
- An important component in the architecture,
vmcb, controls the guest's execution and state; its privileged position (it exposes the content of guest registers) makes it an obvious point of attack; and
- Memory authentication: “The memory is encrypted, but it is otherwise not protected from access. This enables the hypervisor to inject faults into the guest or to capture and replay private guest memory”, they write.
The paper notes that
vmcb and memory authentication are under examination and could be encrypted in future versions, but the paper says that still leaves the general purpose register unfixed, and that's going to be a hard nut to crack: they believe protecting those registers would risk performance and bork device emulation.
The good news is that all of the attacks need a malicious hypervisor – meaning customers can trust AMD SEV if they trust their cloud operator.
Although they consider the design issues to be serious, the researchers note that “the technology is promising” if mitigations are possible.
The Register has contacted AMD for comment. ®
Update: AMD's Gary Silcott has contacted The Register to emphasise that SEV is not yet on products in the field.
His e-mail added that "AMD is pleased to hear researchers see the merit and promise of AMD SEV technology, as it is the first to address protection of data in a virtualized environment and represents a significant step forward in security. AMD along with the rest of the industry, continues to evaluate new threats and develop responses to them. AMD SEV is just one of the critical ingredients in AMD’s security toolbox and the industry can expect to see more security enhancements in the future with our upcoming Naples platform." ®