Re: [PATCH v3 0/4] tdx-guest: Make Quote buffer size dynamic

[Peter Fang]

On Wed, Aug 12, 2026 at 10:22:11AM -0700, Edgecombe, Rick P wrote:
> On Wed, 2026-08-12 at 09:43 -0700, Sean Christopherson wrote:
> > > It seems to me that from the overall solution level, the report should never
> > > have had the details in it. It should just be some nonce or some type of
> > > thing that can tie the guest request to the quote that it ends up getting
> > > back. Doesn't it seem weird to get a bunch of details from the TDX module,
> > > then pass them from the guest to host KVM to host userspace then back to the
> > > TDX module... which already had all those details?
> > 
> > Hmm, my mental model of this is that the report contains the "real" payload,
> > i.e. the metadata describing what is running and whatnot, while the quote
> > effectively signs the payload to prove the provenance of the report.  That's
> > why I view the report as TD-specific (what's running) and the quote as
> > platform-specific (provides root of trust).
> 
> Argh. So I think I was not clear enough in the description. And hopefully Peter
> will appear soon and clarify this is all correct, because I'm relaying what he
> explained to me. 
> 
> We think quote *operation* can be platform specific instead of TD specific if we
> want. Meaning the SEAMCALL isn't passed a TDR. But the bits that actually are in
> the resulting quote are TD specific. In other words, at least some of the bits
> in the report end up in the quote too. Those TD specific bits either come from
> the passed in report, or added later during the quote operation based on the TDX
> module's TD knowledge. Because of course the attestation needs to know about the
> TD details.

Yep this is correct.

The TDX module has knowledge of the TD itself (obviously)

So:
  1. Do the SGX thing and still carry all the TD details in the report,
     and feed it back to the TDX module (big report, no TDR needed)

Or:
  2. Stop doing that, and just let the module grab what it needs (small
     report, TDR needed)

> 
> Or I guess... if we wanted to hand the report and quote to the verifier as
> separate payloads. Then... from my basic crypto understanding, it could work
> too. Is that your model? I think it would be a major change at least.

Hmm actually I don't think it would work. Not if the quote is in DICE
format (see below).

> 
> But part of this too, is that "DICE" is an industry standard [0]. Some of the
> existing TDX attestation format is TDX specific, and moving to the standard is
> expected to make the verifier better. So TDX does not have full flexibility in
> choosing which bits go where. There is some. But I'm not sure which.

In the SGX era, a lot of this attestation stuff was Intel proprietary
and that caused a lot of pain. To follow the DICE standard the bits in
the report have specific places to go inside the quote blob. IOW the
DICE quote doesn't just carry the report like an attachment, and so the
two can't be separated (not without breaking the standard in some way).

> 
> I think I mentioned this, but what we experienced internally on this feature is
> that basic questions like "where should the quote uABI live" quickly spiral into
> a lot of TDX arch tradeoffs and legacy complications. I'll take it we should
> prove out (1) a bit more to get better clarity on if there are any snags.
> 
> [0] https://trustedcomputinggroup.org/resource/dice-attestation-architecture/