AMD memory encryption technologies [LWN.net]

AMD memory encryption technologies

Posted Sep 9, 2016 5:34 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
Parent article: AMD memory encryption technologies

> Part of that exchange will provide the guest owner with a certificate that allows them to prove that they are truly talking to the secure processor.
However, a sufficiently malicious hypervisor can provide a invalid certificate and patch the code in the guest that checks this certificate.

And likely it won't even be too complicated.

to post comments

AMD memory encryption technologies

Posted Sep 9, 2016 13:33 UTC (Fri) by yaap (subscriber, #71398) [Link] (11 responses)

The user should verify the given certificate and make sure it's signed by AMD. It won't protect against an organization able to extract the AMD root of trust certificate, but in practice it's still better than the current state. I don't think that being stolen by the NSA is big concern for a bank for example ;)

As for patching the code in the guest, it's not possible in RAM and it's not possible if the virtual disk is encrypted with a key provided only to the guest once the certificate is verified as good and over a secure channel. The the HV can only do a DoS (not useful here) but can't tamper with the guest.

Devil is in the details, but it looks ok to me.

AMD memory encryption technologies

Posted Sep 9, 2016 14:03 UTC (Fri) by luto (subscriber, #39314) [Link]

Looks less than okay to me. It's not secure against a malicious hypervisor that tries hard to break it.

https://lwn.net/Articles/686814/

http://www.mail-archive.com/linux-doc@vger.kernel.org/msg...

AMD memory encryption technologies

Posted Sep 9, 2016 21:29 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

The problem is with the client code that checks this certificate. It can easily be patched to accept fake certs.

Various obfuscation schemes would only delay the inevitable.

AMD memory encryption technologies

Posted Sep 10, 2016 2:34 UTC (Sat) by geertj (guest, #4116) [Link] (3 responses)

> Various obfuscation schemes would only delay the inevitable.

I'm somewhat optimistic that the problem can be solved. First, on a meta-level, would AMD pour 10s of millions of dollars into a complicated new silicon feature if it were just obfuscation and no cryptographic security could be had? It's possible but in my view unlikely as AMD have some very sharp engineers.

The solution would use a third, trusted server that runs on hardware you own and trust (this could be in your own data center). You need that server anyway to store the keys to unlock the disk images of your VMs (we don't trust the cloud so we need to use encrypted disk images). The untrusted hypervisor would load an unencrypted initrd that tries to mount the root file system. In order unlock the disk image, the initrd would call home to the configured trusted server.

Before giving the disk encryption key, that trusted server would do a DH exchange proxied via the initrd directly to the remote secure processor. You now have a safe channel between two trusted end points. The trusted server could ask the SP for a hash of the initrd (and any loaders that chain loaded into it.) and of the memory. Those can be checked to match trusted fingerprints. Then the trusted server can ask the SP to start encrypting the VM memory as long as it matches the hash (to prevent races).The memory hash would have to exclude local state. Once SEV is enabled you also likely want to have the SP check that indeed you're talking to your own initrd and not some man in the middle. This can probably be done through some challenge/response mediated by the SP. Once you have validated the integrity of the boot chain, that you're talking to "your" initrd, and that the SP tells you that your initrd is now protected using SEV, I think you've succesfully bootstrapped a trusted VM. You can now provide the disk encryption key and continue the boot.

I do agree that SEV v1 still has some holes, but I think those are not fundamental just limitations of the current implementation:

* Memory is encrypted but not integrity protected. Modifying the encrypted memory at a certain offset will easily lead to crashes that can be exploited.
* The VM control block apparently leaks register contents. This is mentioned in the thread referred to in a sibling to the parent comment.

AMD memory encryption technologies

Posted Sep 10, 2016 2:59 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Basically, you have to establish an unbroken DH chain between your trusted hardware and the AMD secure authentication chip in the motherboard.

It's theoretically possible, but will be quite complicated in practice and likely to have lots of holes allowing a hypervisor to mess with you. It can try timing attacks, random number poisoning and so on.

It's better than nothing as it protects against non-malicious hosting providers, but unlikely to thwart entities like NSA.

AMD memory encryption technologies

Posted Sep 10, 2016 4:19 UTC (Sat) by raven667 (subscriber, #5198) [Link] (1 responses)

> I'm somewhat optimistic that the problem can be solved. First, on a meta-level, would AMD pour 10s of millions of dollars into a complicated new silicon feature if it were just obfuscation and no cryptographic security could be had? It's possible but in my view unlikely as AMD have some very sharp engineers.

That logic does not work in practice, for a related example, look at the engineering effort that has gone into failed DRM systems.

AMD memory encryption technologies

Posted Sep 10, 2016 15:34 UTC (Sat) by geertj (guest, #4116) [Link]

> That logic does not work in practice, for a related example, look at the engineering effort that has gone into failed DRM systems.

That is one example indeed. But in this case I was specifically talking about AMD. It is a high tech company with an strong and reputable engineering culture. In the case of DRM, the tech was driven by the RIAA and the MPIAA which are burocratic monopolists and definitely not tech savvy.

AMD memory encryption technologies

Posted Sep 12, 2016 19:25 UTC (Mon) by davidstrauss (subscriber, #85867) [Link] (3 responses)

> The problem is with the client code that checks this certificate. It can easily be patched to accept fake certs.

Yes, but the guest would probably need to be restarted so the attacker can MitM the negotiation. If gaining malicious control of the hypervisor requires restarting guests to gain access, the attack still becomes a lot more noisy, which is still an improvement over today. I support making systems more tamper-evident even when we can't make them fully tamper-resistant.

AMD memory encryption technologies

Posted Sep 12, 2016 20:00 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

I don't know about this. All security-related changes usually have operational costs, it's not really clear for me that in this case it's really worth it.

Whole memory encryption to thwart simple "pull out RAM chips" attacks certainly makes sense, though.

AMD memory encryption technologies

Posted Sep 12, 2016 20:47 UTC (Mon) by davidstrauss (subscriber, #85867) [Link] (1 responses)

> I don't know about this. All security-related changes usually have operational costs, it's not really clear for me that in this case it's really worth it.

This approach probably has implementation (and maintenance for the implementation), but it sounds like it's the sort of design that a hypervisor or guest OS could use by convention/detection without explicit administrator work (other than, say, turning it on).

> Whole memory encryption to thwart simple "pull out RAM chips" attacks certainly makes sense, though.

It also prevents a machine-local compromise (assuming a way to trick secure boot, exploit a management module, or putting in a USB key with malicious firmware). I'd actually like this on my laptop for the host OS, even.

AMD memory encryption technologies

Posted Sep 12, 2016 20:57 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> This approach probably has implementation (and maintenance for the implementation), but it sounds like it's the sort of design that a hypervisor or guest OS could use by convention/detection without explicit administrator work (other than, say, turning it on).
Not really. It needs active participation from the guest OS and a third party that does remote attestation to provide decryption keys to fully utilize this.

> It also prevents a machine-local compromise (assuming a way to trick secure boot, exploit a management module, or putting in a USB key with malicious firmware). I'd actually like this on my laptop for the host OS, even.
It won't protect your laptop in case of a trusted boot breach. Also, kernel/OS updates will be tricky.

AMD memory encryption technologies

Posted Oct 25, 2016 3:52 UTC (Tue) by immibis (subscriber, #105511) [Link]

That client code might run on another machine physically controlled by the client.

AMD memory encryption technologies

Posted Sep 10, 2016 14:57 UTC (Sat) by bdell (subscriber, #84268) [Link] (2 responses)

Isn't the "guest owner" here the end user controlled system requesting the VM from the hypervisor, not code in the VM? The hypervisor can't patch in bad certificate checks in that case.

AMD memory encryption technologies

Posted Sep 11, 2016 1:22 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

It's the code inside the VM. If you have a trusted external system then you build an authentication chain that includes the guest VM to obtain an encryption key to unlock important data.

AMD memory encryption technologies

Posted Sep 11, 2016 2:18 UTC (Sun) by bdell (subscriber, #84268) [Link]

I guess I was going by slide 10 where the "guest owner" box is outside the box with all the hardware bits. The diagrams with the sequence of steps augment the box with "user". The secure processor supplies info about what was launched after the hypervisor can no longer tamper with it ultimately to the guest owner in slide 15 where it can be validated and authenticated before the disk encryption key is supplied to the VM. I don't see how the guest owner is inside the VM or can be tricked.