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
Secure Virtual Machines and Memory Encryption on Desktop Ryzen?
pFtpr
#6
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.
O8h7w
#7
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.
O8h7w
#8
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).
pFtpr
#9
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.
catsay
#10
Looks like someone actually did the homework and read the linked papers 
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
[LIST] of CPU's most likely immune to Spectre
Ryzen C-State related problems -- what is the root cause?
pFtpr
#11
Either that, or I just couldn't imagine AMD not using an ASIC and searched for information after the fact. 
kuro68k
#12
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.
pFtpr
#13
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 
catsay
#14
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.
Marten
#15
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.
pFtpr
#16
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 
Marten
#17
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.
pFtpr
#18
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.
pFtpr
#20
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.