5 ms·

There's an entire ecosystem of supported services in GCP (or whatever cloud provided you'd be passing on) that you would have to find an alternative for if you

There's an entire ecosystem of supported services in GCP (or whatever cloud provided you'd be passing on) that you would have to find an alternative for if you want to co-locate and manage your own physical equipment. 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.

Spivak 6y ago
Having worked at companies that colo'd and ran on AWS I think the difference isn't as big as you're making it seem. Many of services you "need" in the cloud are only needed because you're in a cloud in the first place. 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.
- theevilsharpie 6y ago
  > 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.
  - Spivak 6y ago
    I mean my current company got our first million users with four used poweredge nodes and two database servers. Since we were using bargain basement equipment we were extremely paranoid about hardware failure and so every little aspect of our app was built to handle 2 whole nodes failing simultaneously and every service running on those boxes in VMs was two-failure redundant as well. 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.
thu2111 6y ago
You can't use the ecosystem of services if you use SEV. Think about it: if your encrypted web server VM stores data in a Google-provided SQL database, your data is no longer encrypted. Or if you're using Google-provided SSL termination, or Google provided key hosting, or Google managed operating systems, or Google-provided AI, or Google-provided log analytics. If you need to protect your data, all of those services are no longer usable.
- theevilsharpie 6y ago
  None of these things are incompatible with a VM running SEV. In fact, since many of Google's managed services themselves use Compute Engine, they may already support Confidential VM's running SEV.
  - thu2111 6y ago
    It's irrelevant. You can't audit those services because they're Google-proprietary software, and you aren't the ones with administrator access to them. 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.

Spivak 6y ago

Having worked at companies that colo'd and ran on AWS I think the difference isn't as big as you're making it seem. Many of services you "need" in the cloud are only needed because you're in a cloud in the first place. 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.

theevilsharpie 6y ago
> 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.
- Spivak 6y ago
  I mean my current company got our first million users with four used poweredge nodes and two database servers. Since we were using bargain basement equipment we were extremely paranoid about hardware failure and so every little aspect of our app was built to handle 2 whole nodes failing simultaneously and every service running on those boxes in VMs was two-failure redundant as well. 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.

thu2111 6y ago

You can't use the ecosystem of services if you use SEV. Think about it: if your encrypted web server VM stores data in a Google-provided SQL database, your data is no longer encrypted. Or if you're using Google-provided SSL termination, or Google provided key hosting, or Google managed operating systems, or Google-provided AI, or Google-provided log analytics. If you need to protect your data, all of those services are no longer usable.

theevilsharpie 6y ago
None of these things are incompatible with a VM running SEV. In fact, since many of Google's managed services themselves use Compute Engine, they may already support Confidential VM's running SEV.
- thu2111 6y ago
  It's irrelevant. You can't audit those services because they're Google-proprietary software, and you aren't the ones with administrator access to them. 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.