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

[Edgecombe, Rick P]

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