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

[Jason Gunthorpe]

On Tue, Oct 20, 2026 at 08:49:43AM -0400, James Bottomley wrote:
> 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.

Yeah, we went through the same thought process as below with Dan some
months ago. We went a bit further to include SPDM too..

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

Yeah, exactly, I hope for a general API for, eg signed quote, that can
carry an indication what format the quote is in, but otherwise the
quote can be shuttled through systemd-report without really having to
enlighten it about any particular technology.

Like ARM just posted their FIRME token for non-CoCo case. In an ideal
world it should just slot in and be transparently picked up by
systemd.

Thanks,
Jason