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

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

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.

> > 
> > 4. Migration-specific case
> > 
> > For the normal user attestation path, the TD report is TD-scoped. For
> > 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.
> 
> I was hoping you could chime in about the thing you mentioned off-list regarding
> *when* the quote operation is needed for migration. As in, what stage of the TD
> lifecycle and how it fits into a KVM VM TD scoped ioctl.

The first step in TDX live migration is `TDH.MIG.SETUP` seamcall. It
is called multiple times on both the source and destination hosts.
The TDX  module keeps the setup session state and drives the protocol
by telling the VMM what to do next through exit codes.

Each call follows the same pattern:
1. The VMM calls `TDH.MIG.SETUP` for the source TD or the destination
   TD.
2. The TDX module reads the optional input buffer and may produce an
   output buffer.
3. The exit code tells the VMM what to do before the next call.

One of the possible exit codes is TDX_MIG_SETUP_GET_QUOTE. It means:
deliver me the quote. The output buffer contains the TD report.

The idea was to pass this directly to QEMU. QEMU would call the
proposed "get quote" ioctl on the TD under migration, and provide the
TD report from `TDH.MIG.SETUP` on ioctl input. QEMU would not need to
care about the scope rules and would just treat the TD report as
belonging to the TD under migration.

The ioctl would then run TDH.GET.QUOTE with TDR for the TD under
migration. The seamcall would handle the scope logic internally. It
would be an internal TDX module detail.

Did you mean this or something else?