feat(dkg): add TDXValidationHook for TDX attestation

[0xHansLee]

Summary

On-chain validator for TDX V4/V5 attestation quotes used by the DKG flow. Mirrors SGXValidationHook in structure (Ownable2Step + Pausable) with TDX-specific quote field offsets.

Identity model (v3 — RTMR3-bound binary, RTMR2-included platform)

Split along the operator / cloud boundary, where "operator-controlled" means the running Go binary:

• Binary identity (operator-controlled): keccak256(RTMR3), whitelisted via EnclaveTypeData.codeCommitment (same path as SGX MRENCLAVE). RTMR3 is self-extended by the kernel exactly once at startup with SHA-384(/proc/self/exe) (see story-kernel #68), so its post-extend value SHA-384(0x00..00 || SHA-384(elf)) is fully determined by the running ELF.
• Platform identity (cloud-managed): keccak256(MRTD || RTMR0 || RTMR1 || RTMR2), approved via the hook's approvePlatform admin. RTMR2 moves into the platform half because it measures TD initrd + kernel cmdline — both boot-image properties decided at TD launch by the firmware/boot chain, never the userspace Go binary loaded from disk after boot.

Why not keccak256(RTMR2) for the binary half: on every direct-launch cloud TD measured, RTMR2 contains the TD initrd + cmdline digest. The story-kernel Go binary is loaded from the rootfs after boot and is never fed into RTMR2 by any link of the boot chain — so a keccak256(RTMR2) rule would commit to a boot-image artifact, not to the running ELF. The v3 split corrects this by claiming RTMR3 explicitly for the userspace binary half.

This decouples binary release governance from cloud firmware vintage rotation, so each axis updates independently. REPORT_DATA[0:32] carries the kernel-bound caller commitment from DKG.register and is compared against expectedDataCommitment, mirroring SGX's instance binding.

Onboarding flow

A TDX enclave type is enabled in two steps:

1. Governance: DKG.whitelistEnclaveType(enclaveType, { codeCommitment = keccak256(RTMR3), validationHookAddr = tdxProxy }).
2. Hook owner: TDXValidationHook.approvePlatform(keccak256(MRTD || RTMR0 || RTMR1 || RTMR2), label).

Contract changes

• TDXValidationHook (new). _computeBinaryCommitment reads RTMR3 at offset 520; _computePlatformCommitment assembles the 192-byte preimage from MRTD (offset 184) + the contiguous RTMR0/RTMR1/RTMR2 block (offsets 376..519).
• ITDXValidationHook (new). Admin surface: setAutomataValidationAddr, approvePlatform, revokePlatform, isPlatformApproved.
• IAutomataDcapAttestationFee: adds 1-arg overload (PR feat(dkg): let SGXValidationHook follow standard TCB via Automata verifier #816 pattern) so standard TCB transitions take effect automatically.

DKG.sol / IDKG.sol are unchanged — ABI/storage compatible with the live deployment.

Adversary cost — both halves must succeed

To pass register() an attacker must produce a TDX quote where:

• RTMR3 hashes to an approved binary commitment, and
• MRTD || RTMR0 || RTMR1 || RTMR2 hashes to an approved platform commitment.

The RTMR3 self-extend can only push values into RTMR3 (RTMRs are append-only). An attacker binary B' that self-extends RTMR3 with SHA-384(honest_B) to forge the binary commitment still has to be loaded by the boot chain — which measures the kernel image + initrd into RTMR1 and the initrd + cmdline into RTMR2. Either modification shifts the platform commitment off any honest entry, and the platform-approval check fails.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[wiz-837b06c6da]

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	-
Sensitive Data	-
Secrets	-
IaC Misconfigurations	1
SAST Findings	-
Software Management Findings	-
Total	1

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

[jinn-agent]

The new TDXValidationHook contract is well-structured and its field-offset arithmetic and assembly extractors look correct. A few reliability and deployment-safety concerns remain.

Highest concern: TDXValidationHook inherits PausableUpgradeable but never exposes pause()/unpause(), and validateReport carries no whenNotPaused guard — the emergency-stop capability that justifies the inheritance is completely non-functional.

Deployment risk: setTDXValidationHook() is now called unconditionally from setPredeploys() (the DKG_INCLUDE_TDX flag from the prior review was removed rather than set to false). Every chain — including mainnet — will whitelist enclave type 2 with the placeholder keccak256("TDX_BINARY_COMMITMENT_PLACEHOLDER…") code commitment and two pre-known GCP platform commitments. The placeholder values are publicly computable, so any quote that Automata passes with RTMR3 = SHA-384(TDX_BINARY_COMMITMENT_PLACEHOLDER_v3_RTMR3_self_extend) would satisfy all checks on a live chain.

Deployment script sentinel: TDX_CODE_COMMITMENT = 0x000…0002 in DeployTDXValidationHook.s.sol is a hardcoded placeholder; running the script as-is on a real network whitelists a well-known value.

The CI action upgrades (setup-go@v6, pnpm/action-setup@v4) look fine.

Coverage note: the TDXValidationHookStorageLocation constant cannot be mechanically verified here — operators should cross-check it equals keccak256(abi.encode(uint256(keccak256("story.TDXValidationHook")) - 1)) & ~bytes32(uint256(0xff)).

---

Review iteration 3 · Commit 61fe8be · 2026-05-29T06:02:27Z

[jinn-agent]

Found 1 critical issue(s) that need attention.

[stevemilk]

should be false here?

[0xHansLee]

Removed the constant and make the script set TDXValidationHook contract by default in ddf3d7d