But it’s worth looking at exactly what it means to attempt isolation of programs on shared hardware. SEV is an interesting way of working on it.

It seems pretty clear that your data could never be modified or read, but there’s nothing preventing starvation of resources or side-channel attacks to leak encrypted values.

Of course I also always argue against using the cloud for anything sensitive as “the cloud is really, just someone else’s computers”. Albeit with a fancy provisioning api and some proprietary services adjoining it.

This is too simplistic: employing that argument obligates you to show how you’re mitigating the same threats on your own, especially with regards to ops and security staffing. I have considerably more confidence in any major cloud provider having robust internal monitoring than the typical corporate VMware deployment, and that even extends to bare metal unless you can air-gap it — if you get a bare metal server from AWS, Azure, Google, etc. they’ve still put more work into the firmware, management interfaces, etc. than most IT groups do and those are very juicy attack surfaces.

For me, I can say plainly: "this piece of equipment has these access controls, both physical and virtual and we have various radio frequency dampening systems" etc;

For you, you can think about outsourcing that responsibility.

There's no "right" answer, some cloud providers may indeed have much stricter access controls than I could ever have (for instance, budgets may require my servers to exist in a physically shared space, albeit in my own racks; those racks being porous to allow airflow). But ultimately you will never have more control than if you have complete ownership and audit capability of all systems.

I'm sure many people have lived in the same regulatory hell that I have; and I wouldn't argue that the regulatory hell is easier in the cloud or otherwise; I would instead argue that if I was the CIO; I would sleep better knowing I had done my job and not attempted to outsource the responsibility and wash my hands of it, which is what you're effectively doing, even if you trust the cloud provider, even if they've shown good faith- it's no longer your eminent domain to oversee.

But I can see how you read it that way.

I would definitely challenge you on 'wrong for a significant number of people' because if you're focusing on security then it's likely a core principle; and therefore you need to understand and be able to effectively argue your case.

And that doesn't matter if you agree with my position or not for that last point to be true.

And its often cheaper has better performance and no lock-in to a cloud provider.

The more logical alternative (without abandoning the cloud entirely) would be to use the cloud provider's dedicated instance functionality (GCP's terminology for this is "sole-tenant nodes"), but these are much more expensive than virtual machine instances, especially if you don't need the capacity of a dedicated node. At some point, you or your bosses are going to be asking if the security is _really_ worth the premium.

SEV-enabled VMs can provide a convenient middle ground -- more protection than just a hosted VM instance, but since you're still sharing physical resources, the cost is closer to a VM than a dedicated instance.

If SEV VMs are considered the equivalent of dedicated instances from a compliance perspective, this could open the door to cloud hosting for a variety of industries who were unable to do shared hosting before. However, that if remains to be seen.

The good news about colo'd equipment is that it's dirt cheap. You can have millions of customers running on a few poweredge nodes with full redundancy and capacity to spare.

As someone that actually manages "a few PowerEdge nodes," you're overstating their capability and oversimplifying what it takes to run a production-grade system with millions of users.

I mean ops isn't simple no matter where you're hosting it but it's not any harder than when I worked at AWS shops.

If you need to protect your data, all of those services are no longer usable.

This stuff is new, so I think there's going to be a lot of confusion about what it means and how it works. But the basic concept is easy. SEV and SGX don't mean anything except that you can remotely audit a piece of software that's running by checking the hash of the code that was loaded, and that code can derive private encryption keys unavailable (in theory) to any other piece of software on the system, and that its memory is encrypted.

In SEV that piece of code is effectively the entire OS. In SGX it's a much smaller piece of code, more like a single shared library.

With a Google managed database system, you don't know what software it precisely is. These clouds aren't open source. Even the hypervisors aren't open source, as far as I know. Even when based on an open source product there are proprietary patches. And, they change constantly.

That means if your VM starts up and you get a hash back saying it's the OS you wanted to start, that's great, but the moment you open a connection to some other server even if it's all running on AMD hardware, all you get back is a hash and moreover (iirc with SEV) a random hash that's only useful if you're actually the one that started the remote VM. With SGX you get the actual code hash and/or code signing key, even if you didn't start it, which is a bit better.

What does that hash actually mean? Unless you can reproduce the build of whatever you're talking to and audit the code to look for back doors, and keep auditing it as it changes, it means basically nothing. That's why SGX focuses on really tiny pieces of code - less attack surface, but also less audit churn and easier reproducibility.

Ultimately to have guarantees your data is private in a cloud, you need either to audit the software stacks and rely on hardware roots of trust, or you can use clever forms of encryption like FHE. But just ticking a check box by itself does nothing at all.

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.