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?
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.
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?