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 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
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.
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).
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.
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
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.
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.
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.
