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

From: Mimi Zohar

Date: Wed Oct 21 2026 - 15:05:48 EST


On Wed, 2026-10-21 at 11:35 -0300, Jason Gunthorpe wrote:
> 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!

Agreed, I hope you don't have to tackle it either.

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

To avoid interleaving the logs, AI had suggested multiplexing or virtualization
of the RTMRs. Whether is has any merit, I'll leave to you. Here's the very
short AI explanation:

"Instead of allowing external drivers or subsystems to execute a direct, raw
extend command to a specific hardware register index, the new attestation
subsystem should act as a Hypervisor for Registers."

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

That would definitely be a plus.

Mimi