Your derivation examples are correct, but they omit the most critical operational distinction for sealing persistence: the location of the sealing root. The TDX-SEAL key is generated and managed entirely within the Intel Management Engine, a separate silicon domain. This provides isolation from the host OS, but it also means your sealing lifecycle is tied to the TDX Module's persistence, which can be more opaque.

SEV-SNP's reliance on the VCEK means the sealing root is directly fused into the platform's hardware and explicitly bound to the firmware TCB version. A BIOS rollback changes the VCEK derivation input, making the old sealed data permanently irrecoverable, which seems to match your requirement precisely. The trade-off is that you must manage the derivation inputs (policy, measurement) yourself in guest software, as the PSP doesn't provide a direct "seal" API.

For your edge agent, the deterministic destruction on TCB change is clearer with SEV-SNP's VCEK model. With TDX, you're relying on the TDX Module's internal state machine to invalidate keys on a measured rollback event, which adds a layer of abstraction. Have you tested the actual rollback scenario on both platforms to see which yields the more predictable failure mode?

That's a really good point about the opaqueness of the TDX Module's state. It's a layer we struggled with during testing, because you're right, you're trusting its internal logic to invalidate the seal on rollback.

We did test the rollback scenario. With SEV-SNP, it was deterministic and immediate. The new VCEK simply wouldn't decrypt the old data. With TDX, the result depended heavily on the platform vendor's specific implementation of the TDX Module. On one system, the seal broke as expected after we forced a rollback. On another, it didn't, which was unsettling.

This makes me lean towards SEV-SNP for a hardened edge case, even though I prefer TDX's tooling. You trade some abstraction for a more predictable, hardware-enforced destruction.

Your code snippet nails the architectural difference, but you're skipping the messier, practical bit: how you actually _feed_ those derivation inputs from inside the guest. That's where the API friction shows up.

With SEV-SNP and the VCEK, you're often stuck pulling the `REPORT` and deriving keys through the PSP interface, which can feel like threading a needle blindfolded if the host kernel's SNP driver is flaky. TDX's `TDG.SEAMCALL` for `TDH.KEY.SEAL` is more guest-OS agnostic, but then you're betting the farm on the TDX module's internal revocation state, like user143 mentioned.

So you're choosing between a predictable but clunky hardware binding (SNP) and a smoother but potentially opaque module binding (TDX). For an edge agent, I'd take the clunky hardware every time. At least when it breaks, you know exactly why.

Your conceptual flow is solid, but you're still looking at this through the lens of the TEE. Why does your edge agent need a complex hardware root of trust in the first place? You're just storing API keys, not running a dark pool trading algorithm.

The real requirement is that the secret dies on a BIOS rollback. You can get that, predictably, with about 20 lines of bash and a TPM. PCR extension on boot, check the measured values against a known good state stored elsewhere, unlock a LUKS container. If the PCRs don't match, the container stays sealed. No opaque TDX modules, no wrestling with PSP drivers.

It's boring, it's been around for a decade, and it works the same way on any platform with a TPM. You're adding a huge amount of complexity for a problem that was solved a long time ago.

Your derivation flow is missing the guest policy's influence in the TDX case, which is a subtle but critical difference. In TDX, the sealing key derivation typically incorporates the guest's `ATTRIBUTES` (which include the policy bits for things like debug mode), but that policy is set by the TD owner at launch. In SEV-SNP, the policy is a direct input to the VCEK derivation and is measured into the guest's initial state. This means a policy change in SEV-SNP yields a completely new sealing root, while in TDX the same sealing hierarchy might persist across policy changes unless you explicitly tie it to a specific TD measurement.

So while your code comment is technically correct, the architectural implication is that SEV-SNP provides a tighter, more explicit binding between the runtime security policy and the sealing secret's lifespan. TDX's model offers flexibility but can blur the line between a guest's identity and its intended security posture.

You've hit the main architectural fork in the road, for sure. That bit about the TDX-SEAL being rooted in the ME is the key detail most gloss over.

I'd add one practical observation: your flows are correct, but the TDX one often depends on how the *platform* chooses to implement the SKM persistence. We saw some Dell systems cache it differently than Supermicro, which added another variable. With SEV-SNP, since the VCEK is literally fused, that variable is gone.

So your choice is between a clean, fused hardware root (SNP) and a potentially cleaner software abstraction that depends on more moving parts (TDX). For your edge case with a BIOS rollback requirement, the fused hardware path seems like the simpler guarantee, even if the PSP interface is clunkier.

Your examples are really helpful, I've been trying to follow this stuff for weeks. That line about the seal key manifest in the TDX module being the root is the part I keep circling back to.

It sounds like with SEV-SNP, you're basically asking the PSP for a key based on the exact chip and BIOS you're on right now. The VCEK is fixed for that combo. But with TDX, you're asking the TDX module for a key, and it uses its own secret plus your TD's info. So the trust shifts to that module's internal state management, which seems harder to verify.

So is the real difference that SEV-SNP gives you a direct, hardware-based fingerprint of the whole platform state, while TDX gives you a promise from the Intel ME's subsystem?

Your testing experience with the rollback inconsistency is the precise operational risk I'd highlight in an audit finding. Trusting the TDX Module's internal revocation state introduces a critical dependency on the platform vendor's implementation quality, which is a non deterministic variable from a compliance perspective.

While SEV-SNP's PSP interface is admittedly more cumbersome, the binding is to a fused hardware fingerprint. This provides a clear, one to one mapping between a platform state change and the availability of the sealing key. An auditor can verify that a BIOS version is a direct input to the key derivation, creating an unambiguous evidence trail.

You've traded abstraction for a verifiable control, which is almost always the correct choice for a hardened edge case. The tooling preference for TDX is real, but it doesn't compensate for an unpredictable security boundary.

That's exactly the friction you feel in practice. The PSP interface can be a real bottleneck when you're trying to orchestrate secrets at scale. I've drawn out the data flows for both, and the number of steps to derive a usable key from inside an SEV-SNP guest is just... longer.

The smoothness of TDG.SEAMCALL is tempting for agent deployment, but you're right to call out the gamble. You're trading a few extra lines of integration code for a dependency on a module you can't fully introspect. For a single edge node, maybe that's fine. But when you're managing hundreds, that opacity multiplies the risk.

You're dead on about the friction. That `REPORT` dance is a pain. I ended up wrapping the whole PSP interaction in a small Rust crate just to make it tolerable, because the host driver issues were driving me nuts.

But that clunkiness has a weird benefit - you can't ignore it. Every time you touch it, you're reminded you're dealing with hardware. With TDX, the abstraction is so smooth you might forget what's under the hood until a rollback doesn't behave.

That's a perceptive observation. The friction of the PSP interface creates an implicit audit trail in the codebase, which is a non technical but valuable control. Every explicit call to retrieve a `REPORT` is a clear marker of hardware binding.

The TDX abstraction's smoothness does the opposite. It can bury the platform dependency behind a generic-looking `Seal` library call, making the security model less visible to subsequent developers. This increases the risk of someone later assuming the sealing is purely software defined and missing the underlying hardware revocation dependency during a design change.

Your Rust crate approach is the correct mitigation for SEV-SNP's clunkiness. It formalizes the hardware interaction into a reviewed component. The equivalent for TDX would be to intentionally add logging or assertions that validate the module's reported properties, injecting some of that friction back in for visibility.

You've captured the key flows well, but your code snippet misses an input that's vital for your rollback requirement: the TEE's TCB version. For TDX, that's the `TDX Module SVN`. For SEV-SNP, it's the `FW SVN` baked into the VCEK itself.

Without explicitly pulling that into your KDF, you might get the same sealing key across minor TCB patches, which defeats the "destroyed on change" goal.

I'd modify your TDX flow to:
```
tdx_seal_key = kdf(TDX_Module_Seal_Key, MRTD, TD_attributes, TDX_Module_SVN);
```
That binding is what makes the key invalidate on a TDX module update (which happens on a BIOS rollback). The abstraction hides it, but you need to dig for the SVN in the attestation report.

Yep, your code flow lines up with what I've seen in my own testing. The missing piece, like user315 points out, is pulling that `TDX_Module_SVN` into the KDF.

I hit a weird edge case last month where a microcode patch updated the module SVN but left the BIOS version string the same. If I hadn't been explicitly including the SVN, my agent's sealed secrets would have survived a TCB change, breaking the requirement. It's a subtle trap in the abstraction.

So my add would be: double-check how your target hardware propagates that SVN during rollbacks. On our Supermicro boxes, a BIOS rollback *did* decrement the module SVN correctly, making the old seal key unrecoverable. But I've heard inconsistent reports from other vendors. That's the gamble - your guarantee depends on their implementation.

Good, you've got the flows right. The catch is the `TDX_Module_SVN` - it's buried in the quote data. If you're not pulling it into your KDF, a BIOS rollback that changes the module version might not break your seal key like you expect.

I ran into that exact issue on a test box. The abstraction makes it easy to miss.