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

[Jason Gunthorpe]

On Sun, Oct 18, 2026 at 04:53:28PM -0700, Dionna Glaze wrote:
> > On Sat, Oct 17, 2026 at 11:55:05PM +0300, Jarkko Sakkinen wrote:
> > > I wish I had a better picture what is going on.
> 
> Me too. I've spent my Sunday with Claude trying to build some
> understanding of all this stuff, and put together a static site about
> this series.
> 
> https://deeglaze.github.io/scratch/ctlv-site/index.html
> 
> It includes a review that I've personally walked through to ensure it
> wasn't off base, but of course we're all fallible here.
> I haven't decided to email the review comments to the list yet because
> it's pretty thorough for something posted here as an RFC.

It is a really fascinating summary with an interesting construction
for the CTLV part, I hope to read it more carefully this week. Thanks
for preparing it

I'm still digesting the documentation as well and have made some notes
about improvements. I feel like it goes straight to a highly technical
summary and perhaps some kind of more gradual build up would be nicer.

> > Currently we don't have an intention to flow TPM command packets
> 
> If you're not intercepting all extends through other interfaces to the
> registers (e.g., /dev/tpmrm0), then it needs to be clearer in the
> documentation that users not using the interface will break users of
> the interface when they both target overlapping sets of registers.

This is sort of already the existing case with all of this. There is
no way to 'lock' a measurement register so that only one use can write
to it. eg you can't prevent some other user app from opening
/dev/tpmrm0 and trashing the MR your app is using.

That you can do it through this interface is, to me, just more of the
same ...

But yes, it should be made clear where all the overlaps lie. Hopefully
nobody finds this surprising and there already shouldn't be two
userspaces using the same MR.

Jason