How can I believe the software is running on the CPU and not with a shim in between that exfiltrates data?

The code running this validation itself runs on hardware I may not trust.

It doesn’t make any sense to me to trust this.

The CPU attests what it booted, and you verify that attestation on a device you trust. If someone boots a shim instead then the attestation will be different and verification will fail, and you refuse to give it data.

▲

louwrentius 5 days ago | parent [-]

That creates a technical complexity I still don't trust. Because I don't see how you can trust that data isn't exfiltrated just because the boot image is correct.

If you control the hardware, you trust them blindly.

	▲	trebligdivad 4 days ago \| parent [-]
		Your right it is complex; but it's a 'chain of trust' where each stage is in theory fairly easy to verify. That chain starts with the firmware/keys in the CPU itself; so you have a chain from CPU->CPU Firmware->vTPM->guest bios->guest OS (probably some other bits) Each one is measured or checked; and at the end you can check the whole chain. Now, if you can tamper with the actual cpu itself you've lost - but someone standing with an analyzer on the bus can't do anything, no one with root or physical access to the storage can do anything. (There have been physical attacks on older versions of AMDs SEV, of which the most fun is a physical attack on it's management processor - so it's still a battle between attackers and improved defences). [edit: Took out the host bios, it's not part of the chain of trust, clarified it's only the host CPU firmware you care about]