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

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

On Thu, 2026-08-13 at 22:32 +0300, Artem Bityutskiy wrote:
> Mental model
> ============
> 
> 1. SGX-based attestation
> 
> The original SGX-style flow is two steps:
> 
> 1. The TD gets TD report.
> 2. A quoting agent signs that report and produces the quote.
> 
> What is quoting agent: a process using a special SGX enclave.
> 
> Why 2-step: the key limitation is that the quoting agent cannot fetch
> TD evidence such as FW hash or other per-TD data. So the quote is
> conceptually:
>   - TD report body
>   - signature over the report body
>   - trust material such as the public attestation key and certificate
>     chain
> 
> 2. DICE-based attestation
> 
> The DICE-based model keeps the same two-step flow for compatibility,
> but the quoting service runs in the TDX module and can read TD
> evidence directly. As a result, the quote can include:
>   - TD report body
>   - extra per-TD evidence
>   - signature over the report body and the extra evidence
>   - trust material
> 
> 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.
> 
> 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.

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