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

[Sean Christopherson]

On Tue, Aug 11, 2026, Rick P Edgecombe wrote:
> Sean, Dave, Kiryl,
> 
> In PUCK we talked about how the TD scoped quote operation avoids changes 
> in the guest. But this series is actually changing the guest, so is 
> somewhat at odds to that assertion. It turns out there are some tradeoffs 
> here that also connect to TDX migration uAPI. Please see below for an 
> explanation and recommended course of action.
> 
> As a gentle recall helper... The general attestation flow converts a 
> report to a quote, which then gets checked by a verifier. The report is 
> like a snapshot of the guest and its environment. The quote is a signed 
> version of the report plus hardware certs. It's signed with a hardware key 
> and can use different kinds of crypto.
> 
> These pieces are evolving to handle a few problems at once:
> - The stuff that needs to be attested is growing. Basically more platform 
>   details and devices are getting added to the blobs.
> - The crypto stuff is growing. The post quantum crypto stuff is large, 
>   etc. That stuff lives in the quote.
> - Migration wants a quote that is platform specific and not TD specific.
> 
> Because the platform details are growing, they need to either go into a 
> larger report or added later via a TD scoped quote. But the post quantum 
> crypto stuff is going to bloat the quote either way.
> 
> If the report grows to include all the TD specific details, then the QUOTE 
> seamcall can be platform scoped because all the details that it needs are 
> passed in as args.
> 
> But if it is TD scoped, the report can stay the same size and the extra 
> details can just be added during the quote operation. For migration, it 
> only needs a platform scoped quote. If there are extra details about a 
> specific TD, the migration stuff can be fine to just ignore them. (i.e. it 
> can get what it needs from TD scoped quotes or platform scoped quotes).
> 
> The current QUOTE seamcall supports both: platform scoped and TD scoped 
> operations. But since we could get by with either only a platform or TD 
> scoped seamcall for both operations, we could reduce the kernel's uAPIs, 
> or change the API's location. Per recent discussion, Sean sees TD scoped 
> APIs living in KVM and platform scoped things living in the host 
> driver/tip. So all that leaves us with something like this:
> 
>  |Normal quote    |Migration quote |Report size|Quote size|uAPI location  |
> -|----------------|----------------|-----------|----------|---------------|
> 1|Platform scoped |Platform scoped |Grows      |Grows     |TDX host driver|

With my KVM hat on, this option looks very attractive.

And with the caveat that I'm most definitely not an attestation expert, from a
separate of concerns perspective, IMO it seems like the report should contain the
TD-specific information while the quote just wraps that information in platform-
specific goo.

In other words, to me, TD-scoped quotes feel like a hack that was thrown in to
avoid having to modify the guest because y'all didn't plan ahead.

> 2|TD scoped       |TD scoped       |Fixed      |Grows     |KVM            |
> 3|TD scoped       |Platform scoped |Fixed      |Grows     |Both           |
> 
> 
> I'm thinking we should proceed with 2 because only the quote size changes. 
> So less guest changes over time. 3 is not really a disaster either, but we 
> shouldn't need 2 uABIs. For 1, from early discussion it seems it can be 
> made to work but sounds like it will require some more extensive changes 
> to the TDX attestation stuff. So probably needs a bit more investigation 
> before we can say it won't disturb some other VMM vendor, etc.