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

[Artem Bityutskiy]

On Wed, 2026-08-12 at 23:30 +0000, Edgecombe, Rick P wrote:
> Hmm, let me flag Artem to see if he can add anymore weight one way or the other
> from the migration POV.

Hi,

I will just assume the question is: "Is a TD-scoped quote seamcall
fundamentally wrong or acceptable?"

Short answer: I would say acceptable. I see it as a practical tradeoff.

Let me lay out my mental model, which should explain how I came to this
conclusion.

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

Thanks,
Artem.