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

[Jason Gunthorpe]

On Wed, Oct 21, 2026 at 10:12:34AM -0400, Mimi Zohar wrote:
> > > I think for now we should not include a new dynamic log here, the uAPI
> > > around this Jiri drafted can remain a future step. I don't want to
> > > open complicated discussions about new functionality at this
> > > stage. The whole CTLV idea in general is a big enough thing to bite
> > > off for this series.
> > 
> > Okay, dropping the log from this set.
> 
> Thank you.  Please keep in mind going forward, that the scarce hardware register
> limitation (like the 4 TDX RTMRs) should be resolved (e.g. by multiplexing the
> extension path), not by combining distinct measurement lists.

I'm not sure what you mean?

Since the HW doesn't support sealing the only *technical* requirement
is the verifier can reproduce the measurement register hash. So long
as we can get there we can do whatever.

Multiplexing extension alone isn't enough. We need some scheme to
reconstruct interleaved logs too. 

For example we could add an atomic sequence number for each
extend. Every log sharing a register can report the sequence
number. The verifier would have to globally sort all logs to confirm
the hash.

Hopefully we don't have to tackle this problem. I hope that 4
registers is enough for Linux. One for IMA, one for systemd, one for
user? Plus a spare!

Maybe we can build a multiplexed scheme on the spare? I don't know.

But we almost certainly need to have logs sequentially created in time
occupying the same register. Ie IMA may take over the register from
UEFI logging. Here we'd want to report the start/end hash values of
the logs back to userspace so the verifier can stitch the order back
together.

It would also be nice to think about a way to restrict the registers
to help avoid multi-user conflicts from misconfiguration.

Jason