Confidential Computing – Some Thoughts

At the end of 2020, I first came across the term Confidential Computing for the first time over here. This article describes how to encrypt a virtual machine image and then upload and run it on a physical host of a cloud provider without the cloud provider being able to look into the VM and into the virtual disk image. If this was actually offered by a cloud hosting company in the future, it would go a long way to overcome my aversion of processing sensitive personal data in the cloud. Over the next months, however, it turned out that the term ‘Confidential Computing’ is used for quite a number of different things, so one has to be very careful what people mean when they are using this term. So let’s have a look at the different kinds of Confidential Computing.

Real Confidential Computing

Let’s first go back to the Confidential Computing I first read about: The basic idea is to encrypt all but a few places of the virtual memory used by a virtual machine, which for example runs a Linux server inside. The encryption is done directly inside the memory management unit and the key comes directly from a secure enclave, which is basically a chip on the motherboard. As the memory management unit does the encryption/decryption and guards the key, other VMs, processes on the Host VM, and even the Hypervisor can’t see inside the VM. In other words, the server and the data it uses is protected while it is running. For a demo of how that works in practice with QEMU/KVM, have a look at this 22 minute video. For further background on AMDs implementation (SEV-SNP), have a look here.

To be really confidential, however, the server also needs to be protected while switched-off. That means that the complete virtual disk image that resides on the VM host and the BIOS used in the VM needs to be encrypted as well. Furthermore, there needs to be a way that only the owner of that disk image can remotely instruct the security chip to release the secret key to the memory management unit for memory encryption, and also to the virtual machine image, so the fully encrypted VM disk image can be used inside the virtual machine.

Memory encryption and using a fully encrypted disk image that includes all data and code, including the BIOS (which usually does NOT reside there) ensures that the cloud provider (e.g. Amazon, Google, Microsoft, OVH, Hetzner, etc.) can’t see inside the VM. In other words, it can’t modify the BIOS or the operating system running in the VM to get access. This also means that the disk image has to be built and encrypted outside the cloud environment and then transferred into the cloud.

And here comes the trust part: The only pieces of hardware that have to be trusted in the cloud are the the memory management unit and the security chip. The memory management unit has to have your trust because it could potentially have a backdoor to get to the key. And the security chip has to be trusted to only give the secret key to the VM and the memory management unit.

In practice, public/private keys of the security chip manufacturer are used to give an encrypted version of the the secret key to your VM to the security module which then decrypts it and supplies the material to the memory management unit. For more details about that, have a look at the original article I found back in December 2020.

What Others Mean When They Talk About Confidential Computing

When you search for ‘Confidential Computing’ on the net, you will pretty quickly stumble over news of Hyperscalers such as Google and Microsoft that they are now offering ‘Confidential Computing’ and encrypted virtual machines. They even go a step further and promise ‘one-click’ activation. Hm, sounds too good to be true. When looking at the details, it turns out that the ‘Confidential Computing’ they offer is to just encrypt the virtual machines while they are running in memory. The virtual disk image itself remains as it is, i.e. it’s unprotected and can be seen and modified at any time by the cloud provider. Hm, to me, there’s not much confidentiality in that. But why are they doing this then? The main benefit of this approach is to protect running VMs from side channel attacks out of other virtual machines running on the same host such as Rowhammer and Rambleed. But that’s not confidentiality to me, that’s a security weakness mitigation method. So for me, using the term ‘Confidential Computing’ for encrypting memory without doing initial off-site full disk encryption with a secret key is a misnomer.

What Even Others Mean When They Talk About Confidential Computing

And if you still go a bit further down in the search results, you will quickly discover that yet others use the term ‘Confidential Computing’ for methods that different parties can use a pool of data with their code without being able to actually see the data. I’ll leave it to the inclined reader what this exactly means in the world post-blockchain computing…


The initial article that described memory + complete VM image encryption is what I would see as ‘real Confidential Computing’. The memory-only encryption done by Hyperscalers today is just an attack vector mitigation, nothing more. And what yet others mean with Confidential Computing, well, I don’t think I want to go there today. Nevertheless, an interesting topic that will hopefully evolve to real Confidential Computing at Hyperscalers in the future.