AMD memory encryption technologies [LWN.net]

AMD memory encryption technologies

Posted Sep 12, 2016 19:25 UTC (Mon) by davidstrauss (subscriber, #85867)
In reply to: AMD memory encryption technologies by Cyberax
Parent article: AMD memory encryption technologies

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

to post comments

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.