nellydpa

The keys used to encrypt the confidential VM memory is kept in the hw registers and not accessible and extractable by any sw, google or AMD. The keys are per a VM, ephemeral, so not stored anywhere. RE: storage level, you can encrypt your disk on the file system level if confidentiality of the data is important to you, dm-crypt with dm-verity are good choices. I agree with you that Google SREs are probably the best, no argument there.

The answer to your question: The AES mode AMD SEV uses is similar to XEX. AMD computes a tweak value based on the physical memory address and performs an xor-encrypt-xor operation. The tweak algorithm used on Rome (2nd gen EPYC) is based on GF math and uses a random value that is changed on each boot.

Actually, the integrity of the AMD microcode can be verified using Google stackdriver as part of VM audit logs, together with the integrity of the VM kernel.

AES 128bits

But everything else is not actually confidential... Confidentiality means limited visibility, when you process your data, the memory is in clear without this tech, or Intel SGX that offer confidentiality and integrity.

You can access memory within a VM, not outside of a VM. Host machine with a hypervisor is not within a VM instance, so it will not be able to read your VM memory. The memory is encrypted all the time, but when the instruction has to be executed on CPU, memory controllers (only and only have access to the keys of this VM) decrypt the instruction to execute it on cpu in clear. For FHE, cpu instructions are executed on AES encrypted blocks, and will take significant time, so not very practical today. Does it make sense?

You are right, data is private and confidential when it is ingested to the cloud and/or stored in the cloud, not when processed. Encryption of "data-in-use" is the 3rd leg in data protection of sensitive data, and it became possible with hw capabilities in new CPU chipsets, from AMD and Intel, as it has to be hardware based (better security and performance).

Quite a few: protect sensitive data in the cloud from the tenants and cloud providers, protect my clients sensitive data, address some requirements of the regulated markets, mitigate some privacy regulations, and a few new: collaborative computing with untrusted parties?

SEV is targeted to the VM instances, with a single key per VM. SME is applicable to the entire server, similar to total memory encryption with a single key for all host kernel/machine. SME is not super applicable to the cloud, more suitable for a single server environments.

Unless you run a database in the Confidential VM, can run mySQL, postgresql, MariaDB. Google managed db service, say GCP CloudSQL is not supported...

GCP does not have root access to the customers VMs. Confidential VMs with AMD SEV create an additional cryptographic isolation layer (in addition to virtualization one) between tenants and Google infra, mitigate 0days guest escapes, make observability attacks less possible, protect against some set of DMA attacks, and mitigate memory physical access attacks. To add to this not all spectre variants are applicable to AMD SEV, e.g. L1TF or foreshadow is not.

Homomorphic encryption enables computation to be performed on encrypted data without the need to decrypt it on the CPU. Compared to Confidential Computing approaches, the processing complexity of FHE is quite high, especially for tasks that require execution of complicated algorithms, making it hard to scale with this approach. Confidential VMs with AMD SEV decrypt data within VMs and keep it encrypted "in-use" by encrypting memory with a key generated by AMD secure processor (non-extractable) per VM. After processing data and code can be encrypted back to keep it protected at-rest.