[RcouF1uZ4gsC]

> Under the hood, Confidential Computing environments keep data encrypted in memory, and elsewhere outside the CPU. Data is decrypted within the CPU boundary by memory controllers using embedded hardware keys that a cloud provider does not have access to.

I don’t know how much that buys you. If the threat model is that the cloud provider cannot be trusted, can’t the cloud provider just run your software on a machine that did not encrypt memory. After all they control the machines and schedule what code runs on the machines. How could you even detect an attack like that?

EDIT:

Unless you are using some theoretically secure system such as fully homomorphic encryption, if the organization that physically controls the machine your code runs on wants to compromise you, they can.

[anonymousDan]

Look up remote attestation. Essentially it allows you to verify you are talking to your code inside an enclave/encrypted VM.

[darkwater]

I'm reading about it here https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attes... but maybe it's not the best link. From what I understand from Wikipedia, remote attestation works in the scenario in which you are the producer of the TCP enclave, or trust it. And you can know that the software running in there is that specific copy, not a tampered one.

But in this case I think OP was claiming that the google checkbox/dmesg message could be just fake/placeholders and you would not know (unless you can really inspect the internals). Am I getting something wrong?

[gcommer]

If you trust the CPU vendor to not be colluding with your cloud provider, and that the cloud provider hasn't found and exploited a hardware or software vulnerability in the enclave, then a successful remote attestation is a cryptographic proof that you are executing your code unmodified without the cloud provider being able to see either your code or (with careful delivery) your data.

There are additional side channel concerns such as RAM bus sniffing; it looks like the EPYC processors handle that by encrypting all memory accesses. Additional concerns include memory access patterns and power usage monitoring; I don't see these mentioned in any of AMD's SEV whitepapers but they can (with great care) be mitigated in your software.

Disclaimer: I work for Google but nowhere remotely related to this (I know only publicly available information about this product); I happened to do very similar research work 6 years ago in grad school.