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 19:42 -0400, Jason Gunthorpe wrote:
> > 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.
> 
> You guys really didn't make it discoverable when you added DICE? :( :(

Like influence the DICE spec to interop with legacy SGX based attestation? I'm
out of my depth to try to say how possible that is.

I'm also under the impression that the quote was not designed for local
processing in the guest. But rather remote attestation which, usually involves a
helper service that processes the quote. I've never been clear on why that was
desired. But it probably is part of the reason attestation doesn't fit this use
case perfectly.

> 
> > 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?
> 
> See this is exactly what I'm talking about, I don't want to repeatedly
> get into this situation down the road over the next decade.

I'm not sure if I'm missing something. New incompatible standards seem pretty
normal? Sometimes there is a container to specify which type of blob, and
sometimes it is just discoverable by clues in the bits.

I think the thing that is a bit dicey (no pun) with this, is that there is kind
of a backwards compatibility adjacent change for systems giving the new DICE
quotes. This came up in in both discussions with Dave/x86 and Sean/KVM. The
reason why it was considered grumble-ok in the end, was because the full
verification depends on updates to the library for each new platform due to
needing to be aware of new keys. So to actually attest even SGX quotes on a new
platform, library updates are needed to whatever tool or service is being used.
Since the library needs to be updated in any case, it can also understand the
new formats without any impact to the user.

But this didn't take into account this generic API, local quote processing use
case. Which is kind of a surprise and I'm actually still not 100% clear on how
it will be used.

> 
> > 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.
> 
> Is that an existing option? It seems OK?

I think we would have to circle back with everyone that pushed for the host
controlled quote type. Let's see if the library can distinguish them already
too. This attestctl tool... is that something that could consume a library like
this? Or something that would have a no dependency implementation?