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

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

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.

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.

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.

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/