[spaceheeder]

In addition to cloud VMs, I wonder what applications this might have on local systems. Systems that boot from encrypted partitions and can't have the keys recovered by cold boot attacks? Secure graphics acceleration of different guests in a Qubes system? etc.

[geertj]

I believe that the enabling technology for SEV (SME - Secure Memory Encryption) would indeed protect against cold boot attacks. The SME keys are not stored in memory themselves and therefore once the CPU reboots and the SME keys are erased, the memory contents are lost forever.

[fulafel]

DRM and keeping the user from rooting their PC. This is like MS/Intel Trusted Computing on steroids.

[snuxoll]

AMD has had a on-die management CPU (dubbed the PSP - Platform Security Processor) for years now, similar to the Intel ME, this is something completely different. Memory encryption doesn't prevent you from doing anything with your device, as far as userland is aware they still have access to the full address space with no knowledge encryption is happening - the only difference is memory IS encrypted so even if you manage to freeze memory to preserve the charge it will be useless as soon as it is removed from the host machine or it is rebooted.

[comex]

> Memory encryption doesn't prevent you from doing anything with your device, as far as userland is aware they still have access to the full address space with no knowledge encryption is happening

It depends what you mean by "userland". The purpose of SEV is to allow a guest VM (using hardware virtualization) to run without trusting the host, including remote attestation. Traditionally hardware virtualization is used to run a full operating system which was installed at the impetus of the user, but there is no rule that it can only be used for that. If this feature is enabled on desktop parts, it's equally possible for black box DRM software running, say, on a non-virtualized Windows system, to include a small unikernel and automatically set it up to run in SEV mode. The whitepaper proposes that people running VMs in the cloud use remote attestation to upload disk encryption keys such that the VM can only decrypt the disk if it hasn't been tampered with, but the 'cloudiness' could just as well go the other way: cloud DRM servers sending decryption keys, for both video and perhaps the code itself, to enclaves on desktop PCs.

Using SEV alone for DRM would have a significant limitation compared to using the PSP: since all interaction with the outside world is still through the host, it would be hard to prevent the host from grabbing the raw decrypted video data as it leaves. But this still prevents recovering the original bitstream; allows 'perfect' obfuscation of many facets of how exactly the code works; and could probably be used in combination with the PSP in some manner. And in some DRM applications, the ability to grab the output may not matter. Imagine a video game where the bulk of the game was inside an enclave, preventing piracy but also all reverse engineering and modding.

Of course, a video service or video game that only runs on AMD CPUs won't get very popular... but conveniently, Intel is coming out with their own feature, SGX, that provides similar capabilities, though with a different design (it's designed more directly for the DRM use case). One might imagine that eventually most systems will have CPUs that support one or the other.

[fulafel]

> since all interaction with the outside world is still through the host, it would be hard to prevent the host from grabbing the raw decrypted video data as it leaves

Wasn't this part already paved earlier by Microsoft, when Hollywood wanted to guarantee no unencrypted HD video leaves the PC? It might have weaknesses but the principle is already estabilished.

A secure crypto path from black box VMs to smart TVs also leaves the door open for all kinds of nasty scenarios involving TV pwnage. You also will have no way of decrypting the data that the VM exfiltrates from your PC.

[kuschku]

The whole point is that you, as user, can not use your (legally guaranteed right in the EU) to debug software, reverse it, modify it, etc.

That is a big fucking disadvantage.

If I buy software (buying a license also counts, if you’re in the EU, or renting a license), I want to be able to use it like I’d use a table I buy: I can saw one leg off, repaint it, turn it into a chair. I want to be able to mod the game, skin it, theme it, do a total conversion.

This is preventing me from using my rights.

[snuxoll]

I don't see how this prevents any of that. While you are inside the running computer memory appears to you as it always has been, if you need to do post-moterm debugging you are going to need a proper crash dump anyway. This is nothing but a security benefit, it will prevent keys for full-disk crypto from remaining in memory where they can be retrieved.

If you're talking about the PSP or ME then I agree, they are dangerous and the inability to gain any insight into what they do means they should be considered hostile entities (especially if they may have access to the internal CPU memory where the encryption keys are stored).

[kuschku]

If the game is fully encrypted, and the DRM uses PSP or ME to keep the RAM of the game itself at all time encrypted so I can not read or debug it, it directly does prevent that.

[snuxoll]

Yes, but that's a matter of using the PSP or ME, not SME which is what I was discussing. SVE brings some "interesting" things to the table since they could technically spin up a VM to run the game and keep the memory protected from the host, but they'd have to pass the GPU directly into the VM which would cause all sorts of other issues in a PC environment (why the *&!$ can't I tab out of this game!).

[sangnoir]

> In addition to cloud VMs, I wonder what applications this might have on local systems

Here's one application for the red team: AV-resistant malware, rootkits and next generation APTs