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

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

On Tue, 2026-08-18 at 13:37 -0700, Sean Christopherson wrote:
> > 3. Why freezing TD report size
> > 
> > Linux supports 1024-byte TD reports via the `TDX_CMD_GET_REPORT0`
> > ioctl. It is already full, no more TD evidence fits, and changing TD
> > report size would require a new ioctl.
> 
> So instead of adding new uAPI for the guest, TDX adds new uAPI to KVM?  That's
> not a very compelling argument.

I agree this is a weak point. The freezing of the TD report size is only a very
minor benefit that results in less guest changes. I was treating it as a tie
breaker level thing.

The reason to not do the quote as a TDG call is to let the host control
contention on the quote resource (s3m, etc). And if we exit out to the host,
adding a host uAPI (KVM or not) lets userspace decide which quoter to use. And
keeps the quote exit working as before.

Just want to call your attention to some discussion on how far we might want to
take this "kick out to have the host manage contention" pattern, if we want to
resolve other guest locking headaches:
https://lore.kernel.org/kvm/0b5a26492f367f793aab38e4a0d9d6f398340f51.camel@intel.com/


snip

> > Therefore, for DICE-based attestation the TDX module adds new TD
> > evidence in the quote instead of expanding the TD report.
> > 
> > Is this the cleanest approach? Maybe not. A clear separation of
> > concern, with TD evidence in the report and the quote only adding
> > signature and trust material, does feel cleaner.
> > 
> > But on the other hand:
> >   - The quote itself is already a per-TD data structure
> >   - The it is inherently variable size because it contains
> >     cryptographic material and trust data
> >   - A fixed-size TD report means that at least one of them is fixed
> >     size, not both.
> 
> Taking this argument a step further, why even have a TD report?  If DICE-based
> attestation can "add evidence" at quote-time, then just throw away the
> separate report entirely.

I think the folks in this thread have converged on that if you did the whole
thing over without SGX, you don't need a report. But you do still need to pass
something from the guest to the quoter so that the guest can know that the
generated quote it gets back is for itself and not some other TD. (Or some other
extra guest call to check the quote after you get it I guess) A nonce only
"report" is just like the report in that it is some bytes of data that the guest
doesn't look at, but just without the TD details in it. 

So given that we have SGX legacy stuff, leaving the report alone and having a TD
scoped quote (KVM based API) is quite similar to throwing the report away. If
you totally unsupported the ability to do SGX attestation, then you would only
end up with a smaller blob to pass out instead of a 1KB blob. In the end it's
not a huge difference, so might as well leave it able to work with SGX
attestation.

But how can we close this, at this point? This is all being hashed out on the
list now, but the hashing out is long and scattered. It may be inefficient for
you to extract the minimum critical points to decide. We could do a more
condensed writeup for you and Paolo to review?