| > This stuff is new, so I think there's going to be a lot of confusion about what it means and how it works. SEV is a hardware function that provides real-time memory encryption. That's all. Maintaining full confidentiality beyond the boundaries of the processor's memory controller is not within the scope of SEV. Google Cloud's Confidential Computing platform _may_ offer a broader solution with some type of cryptographic guarantee, using SEV as a component of the solution. I don't know how far they are, or if that's the direction that they're looking to take the platform. However, if you're looking for a platform with remote attestation that the computing environment is fully trusted, SEV is not sufficient. You would need a traditional TEE for that. > just ticking a check box by itself does nothing at all. Taken directly from Google's blog post: "Confidential VMs can help all our customers protect sensitive data, but we think it will be _especially interesting to those in regulated industries._" (Emphasis mine) It provides additional hardware-backed protection when sharing a physical machine with other tenants, which among other things, can make shared hosting a possibility for security-conscious environments that previously prohibited it. If that doesn't sound like a useful feature, or you feel that it's theater, then you're probably not the target market for the feature. |
You're demonstrating my point for me. That isn't all, by any means. SEV is primarily implemented in firmware, and provides a form of measured boot and remote attestation. Don't take my word for it:
https://developer.amd.com/sev/
"AMD Secure Processor. Provides cryptographic functionality for secure key generation and key management."
This is literally the second feature of two that it advertises as part of SEV.
Those parts are critical and SEV doesn't really mean anything without it. RAM encryption is only useful if you don't trust the owner of the host hardware. But if you don't trust the host, you can't assume they switched on RAM encryption or booted the OS you asked for into the VM, you have to check it. That's what the remote attestation lets you do.
If that doesn't sound like a useful feature, or you feel that it's theater, then you're probably not the target market for the feature.
I work in regulated markets! And yes, it's true, there's a lot of regulators that can be satisfied with security theatre. The weakness of regulator understanding of technology isn't, by itself, a reason to consider SEV without RA useful.