Reverse-Engineering Google's Hypervisor to Close TDX Attestation Gaps
How reverse-engineering Google's proprietary TDX hypervisor closed the last gap in cloud confidential VM attestation verification.
Verifying a cloud-hosted Intel TDX confidential VM without trusting the provider requires independently reconstructing four measurement values: MRTD, RTMR0, RTMR1, and RTMR2. While RTMR1/RTMR2 derive from VM image components, MRTD and RTMR0 depend on Google's proprietary UEFI firmware, making them far harder to verify externally.
By parsing the UEFI firmware as a tree of labeled memory regions—rather than disassembling machine code—researchers used the TDX metadata table to reconstruct MRTD directly and identified how Google's firmware separately hashes the CFV region into RTMR0.
The remaining challenge was the Hand-Off Block (HOB), which is built by the hypervisor rather than the firmware and varies with VM RAM size. Since Google's hypervisor is closed-source, its HOB construction was undocumented. By patching the Linux kernel to dump leftover memory contents across various VM sizes, researchers reverse-engineered Google's hypervisor-specific layout rules, finding it orders memory regions differently from standard QEMU and includes extra entries.
With the HOB reproducible from just the metadata table and RAM size, every RTMR0 event can now be verified without booting a VM or trusting Google—closing the last firmware-related gap in TDX attestation. Trust in ACPI tables and the firmware binary itself remains, to be addressed in future posts.