If each resident VM is a(n attested) hardware enclave with its own memory encryption key (stored in a software-inaccessible register), a privilege escalation attack from one VM would not be able to yield the contents of the other VMs. The best an adversary could do is deny service to the other VMs, but that's always allowed by the threat model.

To my knowledge, VPSes are generally container'd these days, not VM'd, so SME/SEV doesn't actually work. But yes, this seems to be single-targeted at a specific VM threat.

(Add: another reason to extend this to per-process or per-page encryption, since that would work on containers too.)

That's the right idea. How do we allow per-process or per-page encryption of memory with hardware attested keys? Imagine if you can plug in your own key store from an HSM. This starts to really create some interesting defenses against very common security enterprise threat modeling.

> To my knowledge, VPSes are generally container'd these days

Not true. AWS is still largely on Xen, and most others are using KVM. Serverless (Lamdba) is a different story, but EC2 instances are largely Xen VM's, not containers.