How do I validate an attestation's measurement against a bare metal machine?

[fwoodruff]

I have access to a bare metal TDX host machine. Access is remote but I am able to reboot into the BIOS and make changes at that level. I am in contact with someone (trusted) who has direct physical access to this machine.
I have a TDX-capable .qcow2 image generated using the TDX Canonical repo. which I have run on both this bare metal TDX host, and on a Google Cloud machine. The image, for debugging purposes, has SSH access and I have generated an attestation report with:

report=/sys/kernel/config/tsm/report/report0
mkdir $report
dd if=binary_userdata_plus_nonce > $report/inblob
cat $report/outblob > attestation.bin

I have then extracted the measurement values from this report as generated on Google Cloud and on the bare metal VM. All values except for the Vendor ID and nil values are different. Explicitly, MRSEAM, MRTD, RTMR[0:2] are all different.
How do I configure a bare metal machine so that it produces the same attestation values I get for this image on a c3-standard-4 Google Cloud instance?
Note that I am looking to confirm that Google are in fact running the image I have submitted, without modification and without a firmware backdoor. I am not looking to prove to third-parties that an attestation came from Google Cloud firmware.

[reinc]

Hi @fwoodruff,

Welcome to Google Cloud Community!

It's great that you're trying to verify things, but if you configure your bare metal machine it cannot produce the exact same attestation values as a Google Cloud instance.

Here's are the reasons why:

Google Cloud uses specialized hardware specifically designed for their infrastructure. This includes customized motherboards, CPUs, and firmware that is optimized for their environment. Your bare metal machine, even with identical components, will have different unique identifiers (MRSEAM) and configuration due to the manufacturing process.

Google Cloud uses a custom firmware (BIOS) tailored to their infrastructure and security requirements. This is completely different from the firmware on your bare metal machine, which likely comes from the manufacturer.

We encourage you to create a public issue tracker. However, please note that there's no guaranteed timeframe for resolving it. If you need a workaround or urgent assistance, reach out to Google Cloud Support directly.

I hope the above information is helpful.

[andy-ab]

From my understanding the exact hardware should not effect the measurements.

Instead it is firmware and other software which effect the measurement value and can be verified as per instructions here: https://cloud.google.com/confidential-computing/confidential-vm/docs/verify-firmware

However since the firmware is binary and closed source it's impossible to know the there is not an attack coming from there, we can only verify it is an official Google release (signed). Unless Google open sources the OVHF I don't see the attestation process as adding much value. I've Posted a comment here requesting this:

https://www.googlecloudcommunity.com/gc/Infrastructure-Compute-Storage/Open-source-OVMF-binaries/m-p...