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

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Oct 22, 2026 at 10:07:33AM -0400, James Bottomley wrote:
> On Thu, 2026-10-22 at 10:11 -0300, Jason Gunthorpe wrote:
> > On Thu, Oct 22, 2026 at 08:26:29AM -0400, James Bottomley wrote:
> > > On Wed, 2026-10-21 at 11:35 -0300, Jason Gunthorpe wrote:
> > > > Maybe we can build a multiplexed scheme on the spare? I don't
> > > > know.
> > > 
> > > Direct sharing of PCRs is certainly possible, but not in all
> > > circumstances. To share a log, each logging entity must record
> > > entries in such a way that the relying party can disentangle them
> > > with absolute certainty.  The problem with the latter is that both
> > > the TCG and the IMA log format have unmeasured (or advisory) log
> > > entries.  You can fool a relying party trying to disentangle a
> > > combined log simply by converting the advisory entry of one logging
> > > entity to being the advisory entry of another and bingo, it
> > > disappears from the other log.
> > 
> > My understanding was the unmeasured entries exist only to help the
> > verifier understand the log structure, and what data is in the
> > log. Like you might record a firmware version so that the verifier
> > can locate the reference measurement.
> > 
> > If they are corrupted somehow then the verifier should fail to
> > understand or reconstruct the log and fail the verification. 
> 
> That's true, but only if you know the entire log consists of your
> measurements.  Because you know, ipso facto, that you should be able to
> understand them all.

Yes, you cannot start processing any log entries whatsoever until they
have been verified by the Merkle tree calculations.

With a shared PCR the Merkle validation would have to be done in one
pass, with knowledge of how to put together all the shared logs.

For example, if we imagine a scheme where we create vPCRs then every
vPCR extend could have a common log bound to a RTMR of
something like:
 {extend vPCR #10 to hash XYZ}

The first verifier pass evaluates this log, confirms its merkle is OK
and ends up with current values for all the vPCRs. Then the individual
logs associated with the vPCR are merkled up just like a real TPM
would have done.

Advisory entries shouldn't matter with a scheme like this.

There are other ways to do this, but the general notion requires that
the log entries are, in some way, self describing so anyone can do the
Merkle calculation for them.

It doesn't work for sealing, but for remote verification systems it
seems like it might be something interesting for userspace to do?

Jason