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

[Sean Christopherson <seanjc@google.com>]

On Thu, Aug 13, 2026, Artem Bityutskiy wrote:
> IOW: in the SGX-based design, it is impossible to add TD evidence to
> the quote. In the DICE-based design, it is possible.
> 
> But the question is - OK, it is possible, but why should it be done?
> 
> 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.

> Also, as I understand it, based on TDX feature requests from customers, there
> may be a need to increase TD report size more often and more significantly
> than one would expect.

Who cares?  And I mean that literally, i.e. "who" as in "what chunk of code is
negatively affected if the TD report size changes".  "GET" ioctls whose payloads
have varying size aren't novel, nor are they particularly difficult to implement
or work with.  What's so bad about adding e.g. TDX_CMD_GET_REPORT0_2 to allow for
a variable sized payload and any other mistakes we made with TDX_CMD_GET_REPORT0?

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

> 4. Migration-specific case
> 
> For the normal user attestation path, the TD report is TD-scoped. For

That's not a TD report.  Call it whatever you want, but it's not a report about
a TD.  If the claim is that "TD" can mean something other than a TDX VM, depending
on the context, then that needs to stop, because there is no way anyone is going
to be able to follow along.

> migration, the report is effectively platform-scoped, just because the
> migration flow does not need TD-specific evidence.
> 
> I would say that clean design is when Linux does not need to know this
> and care about this specific case: be able to treat all TD reports as
> per-TD.