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

[Jason Gunthorpe]

On Mon, Nov 02, 2026 at 07:02:37PM +0000, Edgecombe, Rick P wrote:
> > Though I am planning/hoping to have a sane admin tool here as we agree
> > to things, so admin can do like:
> > 
> > $ attest report
> >    TDX Report:
> >      Xyz 
> >      Abc
> >    TPM Report:
> >      124
> >      435
> 
> Hmm. TPM report is a signed thing right? But "TDX report" is not. Or "TDX
> report" is really the TDX quote?

Yeah, the signed thing.

Sounds like in the TDX language it is TDX quote. ARM CCA calls their
signed thing report. systemd calls the entire aggregate bundle the
report. I think TPM called it quote. Isn't it nice everyone has their
own words?

Jiri, I suppose we should meditate on what word you use in the schema
to try to be clear.

> I still don't see the need to expose the TDX report (TDX definition
> of report) through a generic interface.

Great, let's not do that. Signed things only is what I was expecting,
because that is what systemd needs when it generates its aggregated
"report" to send to verification.

> Are you thinking about having any kind of community
> call for TSM? Maybe we could walk people through TDX attestation.

If we have to, but it is more inclusive if the mailing list has a
record of such things..

I was thinking of trying to organize some smallish summit type call of
a longer duration when this is more solidified and everyone has time
to digest it so we can go over *everything* and confirm people are
happy. This would be a 'come prepared' kind of call, instead of a
physical conference. Let's see

> > > On the TDX side we would have to work through how to ask for a
> > > specific type of quote. In the initial set we have planned, the host
> > > will decide.
> > 
> > That's fine. Broadly the "default" report format should be set by the
> > VM's instance type, eg defined by the CSP. It should not change
> > launch to launch of the same VM.
> 
> In the attestation space, it seems there are people who want many
> slightly different things. And it has been generating option
> complexity on top of the TDX legacy baggage.

Yeah, I am aware.. Above has been my view as the only logical position
for a CSP to take. If you change the format of the TDX quote from
launch to launch you risk ABI breakage with the customer's
verifier. You will have angry customers if one day their VMs boot and
they don't verify anymore.

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

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

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.

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