Re: [PATCH RFC 00/20] attestation: Add a common subsystem and TDX support

[James Bottomley]

On Sat, 2026-10-17 at 17:34 -0300, Jason Gunthorpe wrote:
> On Sat, Oct 17, 2026 at 11:16:07AM -0700, Dionna Glaze wrote:
> 
> > > About 3 months ago we started looking simultaneously how to
> > > support roots of trust (ROT) HW in place of TPM and how to
> > > respond to the feedback on the netlink proposal for the TSM SPDM.
> > 
> > Given that I was tagged on this thread and not that one, I'd
> > appreciate a pointer to which you mean.
> 
> https://lore.kernel.org/all/20260705220819.2472765-2-djbw@xxxxxxxxxx/
> 
> And then later this:
> 
> https://lore.kernel.org/all/20260921131911.532d81f4@xxxxxxxxxx/
> 
> Basically: No netlink.

That may be the local driver for this particular patch set, but the
conversation about how general a system for tracking attestations
should be is much older.  When this all first started as coco TSM, it
was very much an Intel only RTMR tracker for TDX.  The arguments for
adding TPM2 are simple: SEV-SNP doesn't have RTMRs, so if the system
were to cover non-Intel confidential computing then it would have to
include TPM because the way SEV-SNP was going with the SVSM was to
include an enclave protected TPM to do the post launch measurements.

However, the next observation is that there's really nothing
Confidential Computing specific about this (it's just exposing
measurements and log entries) so if it were to be provably general, it
should also work for the existing TPM logging and attestations of
measured boot, so it seemed reasonable to add that from the beginning
to make sure of the generality.

Finally, there are uses for non-repudiable logging even from user space
(attested build systems for instance, or the use case we had when I was
at IBM: attested firewall changes) so if the kernel exposed a generic
system for doing this regardless of underlying technology that would be
great.

I get that there are some things that can't be generalised, like the
form of the signed quote which is highly technology specific, but it
does look like the logging and extension piece is similar enough to
admit a unified interface.

Regards,

James