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

[Peter Fang <peter.fang@intel.com>]

On Mon, Nov 02, 2026 at 08:58:51PM -0400, Jason Gunthorpe wrote:
> 
> > > If you also want to have a way to query specific types, like AMD's
> > > guid thing, then that's fine too. But I think integrating into systemd
> > > report might be a bit tricky so I'm not sure it is a great idea.
> > > 
> > > In all cases the format of the report is labled, passed to userspace
> > > and given to the verifier. I see Intel already defined DICE format as
> > > 'larger than 8k'.
> > 
> > I'll have to check (or maybe Peter can chime in) if there is some easy label to
> > look at.

There are many ways we can label the quotes. For example:

- tdx-quote-sgx-1.0 (legacy SGX quote)
- tdx-quote-eat-cwt-1.0 (ECDSA signed DICE quote)
- tdx-quote-eat-cwt-2.0 (ECDSA/MLDSA signed DICE quote)
- ...

Or, at a finer grain level:

- tdx-quote-eat-cwt-1.0-ecdsa
- tdx-quote-eat-cwt-1.0-mldsa
- ...

But regarding this labeling, I have some questions below...

> > 
> > > We'd probably want to give that a dedicated label in
> > > CTLV land.
> > 
> > Not following what you mean exactly. A CTLV format that contains the report? Or
> > a user ABI way to request a certain format?
> 
> The CTVL output will always be something like {label, data blob}, for
> everything so it is self described.
> 
> Since the DICE and non-DICE TDX quotes sound non-interoperable they
> should have different labels.. I guess? I really don't know the
> details of TDX enough to say.

Yep, they're non-interoperable and won't share the same label.

> 
> > > One of the things I'm quite adament about on the data labeling is that
> > > if something sees Blob type A then it should at least be able to
> > > verify the signature. Further format variation should be self
> > > describing data within the signed payload. If it is so different that
> > > you can't verify the signature then you have to give it a different
> > > label too.
> > 
> > I'll make sure this made it back to our attestation people. (probably someone
> > already picked it up)

With TDX DICE quotes, this is already the case (the signature is
verifiable). This may not be possible with legacy quotes, but they're a
thing of the past.

> 
> Yeah, I'm quite adament about this. I don't want this to turn into a
> funnel for undefined binary blobs that nobody can understand. At a
> minimum the signature has to parse, and at the maximum I'd love to
> insist on a userspace implementation to dump the contents. We will
> see.

Hi Jason,

I think this in general is in line with the TDX attestation design. In
an earlier thread you had said:

  "I think in the way this stuff ended up being used the userspace isn't
  actually aware. [...] The verifier needs to be aware of the format,
  but the collection agent should not need special knowledge."

... which totally makes sense to me.

What pops out at me is later when you talked about data labeling:

  "Userspace would collect all the blobs and the labels then ship them
  to the verifier which has to understand how the data described by the
  label is organized."

For TDX, the direction so far has been to keep the guest as simple as
possible in the attestation process. So the "quote type" knowledge is
pushed into the TDX module and the remote verifier. The host kernel is
mostly tasked with transporting the quote blob from the TDX module back
to the guest. In other words, TDX doesn't have any quote type knowledge
outside of the module itself. And as far as I know, parsing these blobs
is sort of a pain.

The TDX DICE blobs are actually self-describing, meaning the verifier
can follow a schema, parse the blob straight away, and know what's
inside, including how to verify the signature. They're also
distinguishable from the legacy quotes. A launched guest is guaranteed
to have a stable format for its quotes. So this makes me wonder how the
labeling should be done. Do you think it makes sense to just have a
"primary raw TDX quote" label and let the TDX quote blob describe
itself? Also, I think currently there are no plans to add
secondary/supplementary blobs alongside the quote itself.

Thanks,
Peter

> 
> This will naturally force people to use the right labels since they
> won't be able to make a dumper if they don't.
> 
> Jason
>