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 introduces a well-structured TDX backend with good test coverage and clear backend-agnostic abstractions. Coverage is limited by input truncation (most of enclave/tdx/ source files are present but patches are null). A few correctness and reliability issues were found across the visible files.

Key findings:

1. sealdb.Close() silently drops the stor.Close() error when db.Close() also fails — dual-error case is not surfaced.
2. build-sgx/build-tdx Makefile targets forward the user-supplied $(build_tags) variable, meaning BUILD_TAGS=tdx make build-sgx produces -tags "sgx tdx" which breaks the documented mutual-exclusion invariant and will cause a runtime panic on the first enclave.Default() call.
3. make test-cover (used by the CI gotest.yml) now passes -tags sgx, which is fine only if the SGX backend compiles cleanly without hardware — worth verifying the CI run.

---

Review iteration 5 · Commit 313e41e · 2026-06-08T09:23:33Z

[stevemilk]

check if len(providers)>0

[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.