Re: [PATCH RFC 20/20] attestation: Add the TDX family implementation

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

On Mon, 2026-11-09 at 13:12 -0400, Jason Gunthorpe wrote:
> I would be very happy if Intel came with some plan, documented in the
> ABI comments around their labels down the road.
> 
> What I would like is that given a specific label any userspace can do
> a verification and full dump of that data, including signature
> validation, without need of any further external information.
> 
> Ie it is entirely self describing under that label.
> 
> So if someone has to say externally 'oh this was a legacy VM' to make
> parsing work then that needs to go in the label.
> 
> Think of it this way, you should be able to run a command, lets imagine:
> 
> $ attestctl dump report0
>    intel TDX A:
>      - Field 1
>      - Field 2
>    Signature VALID
>    Certificate chain
>       A
>       B
>       C
> 
> It must not be something like:
> 
> $ attestctl dump report0 --kind tdx_legacy
> $ attestctl dump report0 --kind tdx_dice
> 
> Does it make sense?
> 
> Whatever labeling you choose has to follow these goals, and there is
> some trade off between making thing self describing forever into the
> future and exposing protocol details into the guest kernel driver.
> 
> The future scares me so I would always design to include a description
> of the blob from TDX module to the guest driver :)

So we have this SGX based quote format that is fixed because it already exists
in the wild. Going forward we are moving to DICE, but that is a standard format.
So also somewhat fixed. I guess the question is: is there some combo of bits in
each blob we could check that could deterministically distinguish between the
two? To do this we would need to analyze the quote formats.

If there isn't, I'm not sure what we could do at this point. There is a library
Intel publishes (right Peter?) that can verify the quotes. I'd guess it must
have some way to distinguish between the two. Can you check how it does it
Peter?

And then, I guess something like an attestctl tool could attempt to fully verify
the quotes to distinguish them.

Another option would be to teach the whole stack to request specific quotes
types from the guest. Then this new component could only request DICE and never
be surprised by SGX quotes.