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

[Mimi Zohar]

On Thu, 2026-10-22 at 16:19 -0300, Jason Gunthorpe wrote:
> 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.

IMA has something called violations (e.g. open-writers, ToMToU), which are more
than just advisory.  They intentionally invalidate the IMA measurement list
since the measurement cannot be trusted.

Walking the list containing violations will fail.

Mimi

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