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

[Edgecombe, Rick P]

Sorry for the delayed response...

On Fri, 2026-10-23 at 19:00 -0300, Jason Gunthorpe wrote:
> > Yea, it's strange.
> > 
> > The initial TDX attestation navigated some platform limitations. It involved
> > an SGX enclave on the host. The enclave was the thing that did the signing,
> > but it did not have any of the TD details. Only the TDX module did.
> > 
> > So the process to get a quote starts with getting a nonce from the remote
> > attester. Then the TDX module took the nonce and formed it into a MACed
> > "report" that included all the TD details it knows about. Then this report
> > is shuffled out to host userspace, which gives it to the enclave. The
> > enclave just checks it and does the signing. Then the resulting quote makes
> > its way back to the guest.
> > 
> > In the new attestation, the signing happens through the TDX module instead
> > of in an SGX enclave. Since the module already has the TD details, it can
> > just add them itself to the quote. So all it needs is the nonce. For legacy
> > reasons the original TD report is being used for the nonce delivery to host
> > userspace. New TD details are not going to be in the report.
> 
> Sounds like stuff the kernel should be hiding right? Userspace gives a
> nonce and gets back a report, it doesn't care about these details?

It is hidden in the normal attestation flow. I'm actually not sure what the
intention was for exposing it to userspace originally. But in practice, it
enables userspace to use some other guest-host communication channel to reach
the enclave on the host. So like you can run a standard distro kernel but have
some CSP specific channel for some reason.

> 
> If there is a v1 and v2 report because of this then fine, they can be
> labeled that way.

There is only one "TDX report" because it's legacy thing now.

> 
> > So I'm still not following why we would provide the TD report through the
> > standardized interface. Maybe we don't want it?
> 
> My biggest motivator is to get the measurement register stuff brought
> together so we can multiplex it intside the kernel. In that world I
> think it is pretty important that the signature covering the
> measurements be clearly affiliated with the measurement registers
> themselves so there is some hope of userspace figuring it all out.
> 
> attestation subsystem will describe it as one coherent whole, you get
> a single TDX /dev/XX that can do extend and generate a signed quote of
> those registers together. With the same interface as every other ROT.
> 
> IMHO it makes no sense to pull in measurement register and leave
> behind the quote in configfs.
> 
> I grant you there will not be a huge amount of value in moving the
> quote over besides this consistency and ease of use for userspace.
> 
> 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?

You can almost think about TDX report like: "TDX specific thing that is intended
to be processed by the quoting enclave or the TDX module itself".

I've seen many people try to wrap their head around the TDX attestation design
at this point. Everybody thinks "this can't all be needed" and we slowly need to
go through the whole thing.

I still don't see the need to expose the TDX report (TDX definition of report)
through a generic interface. Are you thinking about having any kind of community
call for TSM? Maybe we could walk people through TDX attestation.

> 
> > > So from a TDX perspective, what would you want to have as labeled
> > > blobs for this kind of operation, now and later and maybe someday with
> > > DICE?
> > 
> > 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.

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

> 
> Thus, if you boot instance type V1 you always get the same
> systemd-report format and a stable ABI there for your verifier. When
> you upgrade to instance type V2, the report format ABI can change and
> you have to have a V2 aware verifier to process it. Since everything
> is nicely labeled the error reporting should be better 'verifier
> failed because Intel DICE not support' is way better than 'signature
> failure'.
> 
> 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)

> 
> > Do we think there could ever be a usage for the coco guest to
> > process the quote itself? If the only use is shuffling a blob to the
> > verifier then maybe we don't need this either.
> 
> Probably not, but if you wanted to, then same process applies the
> verifier, you get the label and the blobs and you do the math.
> 
> None of thes concepts are really changing from configfs-tsm-report, it
> is just wrapped into CTLV instead of the creative use of configfs with
> hopefully a bit more robustness on the data labeling.