With this, the party in control of the system is also in control of that, so every time a new vulnerability is found they can exploit it before patching it to retroactively get access to your data. Or never patch it at all and use the vulnerability itself to forge attestations that the vulnerability is patched.

Depending on how determined you imagine your bad actor host, you can probably never get around things like "zero day is discovered, host disconnects guest from internet preventing you from patching zero day, exploits guest".

Or are you talking about vulnerabilities in SEV itself?

In theory you can't actually do it at all. The key is inside the chip, the attacker has physical control over the chip, an attacker with enough resources is going to be able to extract the key. You have no hope against a state-level attacker or even many university research departments. The assumption seems to be that the attacker won't be that sophisticated.

The problem is there are also likely to be attacks which won't require significant resources once published. Researchers are always coming up with new ways to extract keys from "tamper proof hardware" using timing or power consumption or whatever else. Some future version of the hardware will protect against that specific attack but that's too late for all the secrets you trusted to the current version.

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.

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.

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.

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

As if that would work today – look at No Mans Sky, [Alt]-[Tab] already doesn’t work.

Wait 2 years, and we’ll see exactly this. Already today DRM is often implemented as kernel modules, and the OS – especially on windows – prevents debugging for normal users.

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

Homomorphic encryption would allow for "true security" where the party doing the computation doesn't ever have the encryption keys necessary to see what data they're operating on. This is something more akin to a TPM. The key that can read all of the data is in the possession of the party doing the computation, but it's stored in the CPU and the CPU will not give that key to anyone. Theoretically the key could be read off of the CPU but in practice this would require either a flaw, sidechannel, or a lot of time with an electron microscope.

For practical purposes, I believe that all implementations of secure cloud computing are going to be like this where the key is just secured physically. It's possible with homomorphic encryption to have someone securely do computations on data that they can't see all in software, but I just don't see any major breakthroughs happening that would make this fast enough to be practical.

> Attestation uses an on-chip certificate signed by an AMD master key during fabrication.

This is absolutely fantastic for security in the cloud, but it is important to note that this will not protect against nation state level actors.

Rest assured that the USG will obtain the AMD master signing key with or without AMD's permission. Other nation states may do likewise. The rest will have to wait for a leak, and if that key is leaked this feature will become almost nonexistent.

Even a less that perfect protection from the hyper-visor may still have some value.

I'd be more worried about the performance overhead, personally - I can't imagine using this if the impact is significant, and it seems like it almost has to be.

Not necessarily. Bandwidth to main memory is already typically several times less than to L1 or L2 caches. If processor caches are not encrypted, then it seems conceivable that you could have some dedicated encryption/decryption silicon and it probably wouldn't even have to be as fast as it would need to be for general purpose use (like the Intel AES instructions).

Even if it does cost bandwidth or latency to main memory, if it's by a small enough amount it could still be a worthwhile tradeoff for some applications.

Definitely agree. I know we like our security systems impervious to anyone and everyone, be they script kiddie or the entire NSA. However if you hand your machine over to someone else to run, (in either VM guest or box form), I think you need to acknowledge that you are incontrovertibly accepting slight vulnerability to the colo/VM host.