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

On Fri, Aug 14, 2026 at 08:45:55AM +0300, Artem Bityutskiy wrote:
> On Thu, 2026-08-13 at 20:14 +0000, Edgecombe, Rick P 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.
> > > 
> > > 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.
> > > 
> > > 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. 
> > > 
> > 
> > I was thinking the cleanest, time-travel facilitated, approach would be to have
> > the "report" really just be a replay protection thing and not include any TD
> > details. Then the quote could add everything it needed in the final format
> > location. So no re-verifying and shuffling things between formats. But since
> > that didn't work for SGX based attestation, the report has extra stuff due to
> > legacy. But from Linux's POV, going forward we can consider the report as really
> > an oversized replay protection blob and forget about the TD details in it. Isn't
> > it a pretty clean separation of concerns? And for Linux (guest), the benefit
> > shows up in not having to increase TD report size since it has really only one
> > job.
> 
> Replay attack protection is a binding value between the remote party
> and the final quote. It must sit in final quote. It only needs to exist
> in the TD report because of the 2-flow design.
> 
> But why DICE-based attestation uses 2-flow design? Could TD run a
> TDCALL[TDG.GET.QUOTE2] or something directly. No concept of TD report
> would be needed. That would be my current vision of "cleanest".

Yeah, Rick talked about this a bit in an earlier thread [1].

[1] https://lore.kernel.org/kvm/[email protected]/

> 
> But the approach that was taken is to minimize software changes. Within
> that tradeoff, keeping the 2-step flow, preserving the TD report format
> and size absolutely intact, and adding the extra information in the
> quote is arguably a clean practical path.
> 
> Is this the cleanest in some absolute sense? No.
> Is it acceptable? I would say yes.
>