Nearly every isolation mechanism we build on assumes the host is trustworthy and the guest is suspect. Confidential computing turns that around and protects the workload from the infrastructure it runs on.
That is a new capability, not a better version of an old one. It is also the most over-sold idea in the whole isolation business at the moment, so it pays to be exact about which part is real.
The mechanism¶
Memory encrypted with a key the hypervisor doesn't hold, generated and held by the CPU. AMD SEV-SNP, Intel TDX, Arm CCA and the older enclave model of Intel SGX are the implementations.
A hypervisor can still stop the guest, and it can still deny it service. What it's supposed to be unable to do is read the guest's memory, or modify it without that being detected.
What attestation proves¶
This is the part that gets routinely overstated, so here it is plainly.
Attestation produces a signed statement from the hardware saying: this is the measurement of the code that was loaded into this protected environment, and here is a signature chaining to a key the manufacturer vouches for.
What that establishes:
- The launched image matched a known measurement.
- The environment is a real instance of the technology, per the manufacturer's signing key.
What it does not establish:
- That the code is correct or safe. It attests to identity, not virtue. A measured, attested, vulnerable application is still vulnerable.
- That the environment is bug-free. Plenty of side-channel and architectural attacks against these technologies have been published. SGX in particular had a long run of them.
- Anything about runtime state after launch. The measurement covers what was loaded. Whatever has happened since isn't in it.
The TCB, counted properly¶
The claimed benefit is a small trusted computing base. Here's the full inventory:
- The CPU and its microcode
- The firmware inside the confidential-computing implementation
- The manufacturer's key management and provisioning infrastructure
- The attestation verification service, and your own code that checks it
- Your guest image, kernel and userspace included
That last one is the big one for the VM-based implementations. A confidential VM carries a whole guest OS inside the boundary. The TCB is "smaller than one that includes the hypervisor"; it isn't "small".
What this costs you¶
Encrypted memory has overhead. Published figures vary by implementation and by workload, and most of them are vendor-reported, so the open question is a specific one: on a named part, running a named workload, what is the delta against an identical unprotected run? That is a measurement anyone with two identical hosts can take, and the number that would settle the sizing argument for everybody. It is on our bench list and we have not taken it yet.
The second cost is operational and gets mentioned less. You now have a verification step in your deployment path that can fail for reasons that have nothing to do with your software: a firmware level that changes the measurement, a certificate that expires, an attestation service that is down. Budget for it as infrastructure, because that is what it is.
Pay that price and the scenarios become concrete.
A hospital can hand a cloud provider an encrypted dataset and a measured analysis container, get the results back, and the operator never had the records in readable form. The compliance conversation changes from "we trust this supplier's staff vetting" to "the operator was cryptographically unable to look". That is the difference between a two-year information governance negotiation and a procurement decision.
Several banks can compute a fraud signal across their combined transaction sets without any of them seeing another's customers. Competitors can pool data on a shared risk without pooling their commercial position. That class of arrangement has been technically possible with multi-party computation for years and practically impossible because the performance was absurd. Encrypted memory on ordinary hardware makes it a normal engineering project.
And for small operators the effect is levelling. If the host cannot read the workload, then renting a machine from somebody with a datacentre stops requiring that you trust their entire organisation. A three-person company can run something sensitive on rented metal and defend that choice to a regulator. Previously that required owning the building.
Every one of those scenarios depends on who holds the root.
"The cloud cannot read your data" is true and incomplete. The attestation chain terminates at a key held by the silicon vendor. You have not eliminated trust; you have moved it from Amazon or Microsoft to Intel or AMD. That may well be the better trade, because your cloud provider's commercial interest in your data is a good deal more direct than your CPU vendor's. It is a trade and not an escape.
Two or three companies make the silicon that can do this. They operate the provisioning infrastructure, they sign the keys, they decide which firmware versions are acceptable and they can revoke. If confidential computing becomes the way regulated workloads run, then those companies hold a veto over which workloads are allowed to be trustworthy, and there is no appeal and no second supplier. A government that wants to compel something has a much shorter list of doors to knock on than it did when the answer was "every datacentre operator".
The open version is thinner than it should be. You can build your own attestation verification service, and people do; the part you cannot build is the root, because it is fused into a die in a fab you do not own. Open hardware roots of trust exist and they do not run your SEV-SNP guest.
Here at AxisOps our position is that this technology is worth having and worth being suspicious of in exactly the same breath. Run it, verify the attestation yourself rather than letting the cloud's console do it for you, and write down who you are now trusting instead of your hosting provider. A control whose root you cannot name is a feeling.
Where it earns its keep¶
The pattern: it is valuable where operator access is the threat. Against application vulnerabilities, which are what most compromises come down to, it is close to useless. Encrypting the memory doesn't help if the lock on the front door is the thing being picked.