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

[Edgecombe, Rick P]

On Fri, 2026-10-23 at 11:12 -0300, Jason Gunthorpe wrote:
> I think in the way this stuff ended up being used the userspace isn't
> actually aware. It just wants the VM's ROT to sign a challenge and
> forward the resulting blobs to a remote verifier. The verifier needs
> to be aware of the format, but the collection agent should not need
> special knowledge.

So the verifier is a standardized endpoint of some kind...? That makes sense
then. But I think we don't need the report in here then. Just the quote. More
below...

> 
> ie from the perspective of systemd-report it doesn't make alot of
> sense to have it know every single special configfs path and protocol
> for each CC vendor just to get a 'sign my challenge' operation.
> 
> That's the general north star here. We'd like all the vendors to be
> able to do collection without having to change systemd for every new
> innovation. Again I'm looking at 5-10 ROTs in our platforms, it is not
> desirable to go and teach systemd about each of them.
> 
> So broadly, this requires a challenge to go in, a signed blob to come
> out, possibly some suppelmentary blob[s] (like certificates), and then
> labels for what is inside each.
> 
> 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.
> 
> I don't know what "nonce transport blob" means in the future, nonce
> without signature sounds like a strange thing.

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.

So it will become a nonce delivery vehicle with some legacy crud in it.

BTW, there is a spec (GHCI) for how this report makes it way to host userspace.
But since the report is provided to guest userspace, there are apparently other
non-standard ways this transport happens. AFAIU that is the only reason why
guest userspace might want the report.

So I'm still not following why we would provide the TD report through the
standardized interface. Maybe we don't want it?

> 
> > One idea... Not sure on it. We are currently working on support for DICE based
> > attestation for TDX. This is an industry standard and AFAIU other vendors will
> > (want to?) support it too. Perhaps if we could have a single way to ask for for
> > DICE based quote, it could make a cross vendor interface more useful? Callers
> > could just call and get some standard format they can understand. It might take
> > some work on the TDX side to ensure the DICE format quote.
> 
> Yes other people have asked about DICE interfaces for other ROT
> devices. AFAICT DICE is more about having a standard data format, and
> you are right about everything..
> 
> Like SPDM I imagine a set of interfaces defined by the DICE specs, but
> we'd probably still want to have the basic 'sign a nonce' interface
> for opaque transport.
> 
> 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.

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.