SoylentNews

Arthur T Knackerbracket [soylentnews.org] writes:

Story automatically generated by StoryBot Version 0.2.2 rel Testing.
Storybot ('Arthur T Knackerbracket') has been converted to Python3

Note: This is the complete story and will need further editing. It may also be covered by Copyright and thus should be acknowledged and quoted rather than printed in its entirety.

FeedSource: [TheRegister]

Time: 2016-12-08 06:00:11 UTC

Original URL: http://www.theregister.co.uk/2016/12/08/amd_virty_encryption_not_quite_there_boffins/ [theregister.co.uk] using UTF-8 encoding.

Title: AMD virty encryption not quite there, claim boffins

--- --- --- --- --- --- --- Entire Story Below --- --- --- --- --- --- ---

AMD virty encryption not quite there, claim boffins

Arthur T Knackerbracket has found the following story [theregister.co.uk]:

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 [mail-archive.com], 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 [arxiv.org], 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:

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.

Original Submission