Secure Virtual Machines and Memory Encryption on Desktop Ryzen?

Ok so here is the relevant section from the documentation regarding SEV and Memory Encryption

See Page 534

This is the CPU register as read on my machine (1700x) as dumped using cpuid -r

Note: as of yet the version of cpuid I used does not detect these extension. Code is probably incoming for it.

 0x8000001f 0x00: eax=0x00000007 ebx=0x0000016f ecx=0x0000000f edx=0x00000000

Converting register EAX to binary we get

EAX
0000 0000 0000 0000 0000 0000 0000 0111
                                      ↳ Bit 0 = 1 Yay!

So since bit 0 and 1 is 1. That's a yes on SME and SEV

EBX
0000 0000 0000 0000 0000 0001 0110 1111

Here's where it get's funky
Bit 5 - 0 (10 1111 = Dec 47) I'm not sure how to interpret that. Clearly used to enable memory encryption.
Bit 6 - 11 ( 001 01 = Dec 5) Reduction of physical address space in bits. So using 43 bit instead of 48 bit address space?

ECX
0000 0000 0000 0000 0000 0000 0000 1111

To DEC = 15 Secure Virtual Machines supported? This might be offset by 1

EDX
0000 0000 0000 0000 0000 0000 0000 0000

Yip not sure about EDX yet but it's all 0's

4 Likes

EDX has to do with SEV-ES since bit 3 is set 0. Since it is not enable it makes sense that it is zero. As for EBX are you using windows 7 by any chance? because Windows didn't implement the full 48bit addressing until 8.1

This is on a Linux 4.11.6 system. Has nothing to do with windows.

I wonder what is required to enable memory encryption. Some kind of BIOS setting toggle and then it's transparent, or do we need OS level support?

Encrypted RAM is one of the last remaining major security issues for physically secure machines. This is a huge, incredibly important step forward.

It does seem a PR stunt to me... Physical access to a machine is game over....How a Vm cam run encrypted with no performance hit it a hard sell

There is a performance hit, just a minor one. I think they claimed 3% or something, so expect 5-10%. That's perfectly acceptable if it prevents a malicious VM spying on other ones.

Throughput wise encryption is probably not much of a problem. All they have to do is to add an ASIC. The latency is more suprising, but given the extremely high latency of DRAM a few more cycles gotta be close to negligible.

How they are doing it is not with an ASIC, but with an ARM processor (which is on the Zeppelin die). This, I assume, is in order to implement the management parts such as handling the keys and certificates in an efficient way - there is even the possibility to live migrate an encrypted VM from one SEV enabled system to another without decrypting.

Adding a specific ASIC for en/decryption would likely be a very small performance improvement, I'm guessing the die area cost just isn't worth it.

At any rate, indeed an important step. Let's just hope it isn't easily compromised in some way that isn't just as easily patched.

Slightly tangential to topic at hand:

I'd also like to point out that barring any vulnerabilities in this system itself, it actually does away with the notion that "physical access is game over". That's why it is such an important step.

How? RAM en/decryption is happening on die, so unless physical access means inside the die, there just isn't any physical access to decrypted data. And there is a system in place for checking that SEV is enabled upon booting the VM and then not giving it the encryption key to your data if it isn't - so it's not like the administrator can just turn it off.

Back ON topic:

This is, per OP, available on desktop Ryzen. So we can play around with it and test its limits (and have awesome home servers).

1 Like

Yes they are using an ASIC. An ARM processor would not even be close to fast enough for doing this, let alone at ~5% performance impact.
From AMD's paper (http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf)

Each controller includes a high performance Advanced Encryption Standard (AES) engine that encrypts data when it is written to DRAM, and decrypts it when read [...]

The ARM core presumably only handles management like keys, setup and general coordination.

It certainly improves things a lot, but to say it does away with the concept is really pushing it. If you indeed have physical access to the machine there's nothing preventing you from simply manipulating the hard drive. Plus admins will want to be able to migrate VMs between servers. That implies that tere has to be some way of getting the key out of the CPU, lest the new host server lose all of the RAM's contents.

I'm sure more creative people will come up with loads of more ways to get at the data given physical access.

1 Like

Looks like someone actually did the homework and read the linked papers :slight_smile:

Links from the previous thread:

https://lwn.net/Articles/685215/

AMD Memory Encryption whitepaper:
(Currently down)
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer's Manual:
http://support.amd.com/TechDocs/24593.pdf
SME is section 7.10
SEV is section 15.34

Support for the extension exists within the kernel
https://patchwork.kernel.org/patch/9612007/

AMD Memory Encryption Tutorial ISCA 2016
https://sites.google.com/site/metisca2016/

The Intel Equivalent technology
https://software.intel.com/en-us/blogs/2016/02/26/memory-encryption-an-intel-sgx-underpinning-technology

Regarding SEV


A Whole dump of everything else Ryzen technical







1 Like

Either that, or I just couldn't imagine AMD not using an ASIC and searched for information after the fact. :sweat_smile:

Presumably this will protect against cold boot attacks too, i.e. where you take a live system, reboot it and load up a special Linux system from CD/USB drive to dump the contents of RAM. Law enforcement/spies have been known to steal encryption keys that way, for example.

The encryption key used by the AES engine with SME is randomly generated on each system reset and is not visible to any software running on the CPU cores.

(from the same PDF I linked before)

Sure sounds like it.
I don't think that counts for VMs though. Same argument as above: Can't migrate without moving the key as well.

EDIT: Further down in the same doc:

Full memory encryption is a simple yet compellingmodel for many computing systems, especially when physical attacks on the systemare of concern, including government data centers and/orsmaller or remote enterprise data centers that have more limited physical security.With full memory encryption, all DRAM contents are encrypted utilizing the random key which provides strong protection against cold boot, DRAM interface snooping, and similar types of attacks.

EDIT 2: I'll be darned

The interface also provides a mechanism to migrate the guest data to another SEV capable platform. During this operation, the guest’s memory contents remains encrypted during transmission. Once the remote platform is authenticated, the SEV firmware sends the guest’s memory encryption keys securely so the remote platform can run the guest itself.This transport mechanism allows a hypervisor to implement migration and snapshot functions securely with SEV enabled.

How's that even supposed to work? Does the hardware just take over your ethernet now? What about non-standard ways of transmission? Add-in ethernet adapter?
@catsay Does any of the docs you linked have details on this? Won't be reading all of them :wink:

1 Like

Well the information is scattered all over the place through the docs.
But from the looks of it most of it happens via the hypervisor and hv-manager and the CPU PSP really just provides you with a datastream that you get to pipe around the place.

And I'm pretty sure the PSP is able to interface with NIC's in special ways.

1 Like

If the OS has access then the only security is from one VM spying on another. At the OS level it is game over ?

Unless a CPU is being feed random machine instructions decryped in real time its just smoke and mirrors.

The OS does not have access to the keys, so there's no spying there.

Until someone figures out how to read the unencrypted data form the cache that is :laughing:

How does a cpu run code without un-encryting it first. that is the attack vector. Can run encrypted code .... cant not unencrypt it first.

I don't see the problem. The host OS doesn't know the key so it can't read the data. The CPU on the other hand knows the key and decrypts the data before storing it in RAM.

Phyiscal access to a machine mean running any code you want and game over.

Not quite. I sure wouldn't call a machine secure when it can be accessed physically, but in theory with all of the RAM encrypted with an unknown key (unknown to the user/OS/attacker) there's no way to get to the data.