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

[Edgecombe, Rick P]

On Thu, 2026-10-15 at 16:50 +0200, Jiri Pirko wrote:
> Connect the attestation family to the native TDX service. Expose
> TDREPORT, Quote, MRTD and RTMR operations while preserving the existing
> native interfaces.

Along the lines of some of the other commenters I'm not clear on the benefits of
the unified TD/VM attestation part of this.

Especially when you talk about a TD report, it is pretty specific to TDX. So
calling user code is going to need to know about TDX anyway. In fact the report
won't have all the details of the TD either. Going forward it's main function is
to serve as a nonce transport blob and it only has TD details because of legacy
constraints about SGX based attestation. So just a quirky TDX specific part of
the flow on the way to get a quote.

Can you help me connect the dots of why the unification for the TD/VM
attestation helps us get to a wider attestation vision?


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.

Regarding the device attestation part of this, DaveJ (CCed) is exploring this
currently and can share some findings in a bit.