Th cloud provider would be able to provide a message signed by Intel that says "this computer is running only code with hash XYZ at the top privilege level, and

Th cloud provider would be able to provide a message signed by Intel that says "this computer is running only code with hash XYZ at the top privilege level, and the code with that hash has produced public key ABC". The cloud provider would publish the code with hash XYZ, which would be open source and publicly studied to verify the claims that it runs the users' compute workloads securely without allowing other processes to spy on them. The code would create a keypair upon startup, keeping the private key private even from the cloud server operators, and therefore you can know that if you encrypt a message to the public key in the signed message, then only the server's code running with hash XYZ can read the message. You could encrypt your compute workloads (or messages to your own running workload) to that public key and know that the cloud server operators can't read the message. This does require trusting the CPU manufacturer (Intel) though. It's possible that Intel could collude with a server operator to create fake remote attestation messages, and trick you into encrypting your compute workload to them instead of the securely-sandboxed code of hash XYZ. That's not any worse than the current setup where your submitted compute workloads can't at all be encrypted in a way that the cloud operators can't read. Currently, if I want to use a no-name cloud host, then I have to trust the no-name cloud host to not be conspiring against me. With remote attestation, I just have to trust that the no-name cloud host and Intel aren't working together to conspire against me. I trust Intel relatively, so it doesn't matter how shady the no-name cloud host is.