feat(tdx): add TDX backend with configfs-tsm direct adapter

[0xHansLee]

Summary

Adds an Intel TDX backend to story-kernel and aligns the kernel-reported identity with Story's hybrid on-chain TDXValidationHook under schema v3 (RTMR3-bound binary commitment).

• New backend at enclave/tdx/, selectable via -tags tdx / make build-tdx. Implements the existing enclave.TEE / enclave.SealDB contract so service/, server/, and store/ stay backend-agnostic.
• Vendor adapter abstraction at enclave/tdx/platform/ with the upstream Linux configfs-tsm path (direct adapter) as the supported vendor. Runtime selection via STORY_TDX_VENDOR with auto-detect fallback through Probe().
• Sealed storage uses TPM2 PolicyOR over per-provider PCR sets (supportedProviders) combined with an AES-GCM hybrid wrap, so the TPM only seals the data-encryption key. PolicyOR digest population is driven by a bootstrap-mode WARN log so operators can pin the empirically measured digest on first deploy.
• Identity reports codeCommitment = keccak256(RTMR3) to match the hybrid hook's binary half. RTMR3 is self-extended by the kernel exactly once at startup with SHA-384(/proc/self/exe), so the post-extend value SHA-384(0x00..00 || SHA-384(elf)) is fully determined by the running ELF. The chain-side hook independently checks the platform half keccak256(MRTD || RTMR0 || RTMR1 || RTMR2) against its approvePlatform whitelist; the kernel side does not gate on that.
• Startup self-check asserts TPM responsiveness, non-zero PCRs, provider-digest match (or bootstrap-mode WARN), and a quote round-trip whose V4.report_data carries a canary.

How identity flows on chain

kernel side                                on-chain TDXValidationHook
RTMR3 ─── keccak256 ──► codeCommitment ──► whitelistEnclaveType[type=2].codeCommitment
                          (binary half)      (operator-managed; rotates with the ELF)

MRTD ┐
RTMR0│
RTMR1├── keccak256 ──► platformCommitment ──► approvedPlatforms[h]
RTMR2┘    (platform half, derived on chain)    (operator-managed; rotates with cloud firmware/initrd)

The matrix decomposes: N binaries × M platform vintages collapse from N×M into N + M governance rows, and each row tracks exactly one axis.

[wiz-837b06c6da]

Wiz Scan Summary

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

View scan details in Wiz

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

[jinn-agent]

The PR is large and the input is truncated — enclave/tdx/ files (backend, seal, quote, selfcheck, providers, platform/) have null patches and could not be reviewed. Findings below are limited to the visible files.

High-confidence issue found: sealdb.Close() silently drops storErr when dbErr is non-nil. Everything else in the visible surface (noop registration, SGX defensive copies, build-tag mutual exclusion, iterator positioning) looks correct. The prior setup-go@v6 CI concerns are not repeated.

---

Review iteration 11 · Commit 89a3aa1 · 2026-06-22T02:28:08Z

[yingyangxu2026]

#68's 64/65 key-length asserts conflict with the now-merged #844 — please change them to 32/64 before merging.

This PR pins dkgPubKeySize=64 / enclaveCommKeySize=65 in service/utils.go::calculateReportData, with a comment saying they match DKG.sol::register. Both values are now wrong:

1. Out of sync with the contract: #844 (merged into dkg/dev) already changed DKG.sol::register to require 32/64, to align with what the kernel actually emits.
2. Out of sync with the kernel's own output (the more serious one): the kernel's DKG runs on ed25519, so dkgPubKey is inherently 32 bytes; enclaveCommKey is the secp256k1 key with the 0x04 prefix stripped = 64 bytes. This PR would feed the real 32/64 keys into its own 64/65 asserts → registration fails. The current dd7eca07 kernel registers fine precisely because the older calculateReportData had no such asserts.

Pinning the lengths to keep the packed preimage injective is the right idea — just pin to the correct values. Before merging, please change:

• service/utils.go: dkgPubKeySize 64 → 32, enclaveCommKeySize 65 → 64
• service/utils_test.go: validDkgPubKey 64 → 32; validEnclaveCommKey 65 → 64 and drop k[0] = 0x04 (the kernel already strips the prefix, so there's no 0x04 in the 64-byte form)

See issue #73 and story PR #844 for the kernel↔contract alignment.

[jinn-agent]

Found 4 critical issue(s) that need attention.

[ramtinms]

👏 nice work

[0xHansLee]

Let's hold to merge this PR until releasing v0.2.0.