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

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Oct 20, 2026 at 09:45:13AM -0400, Mimi Zohar wrote:
> On Mon, 2026-10-19 at 09:10 -0700, Dionna Glaze wrote:
> > On Mon, Oct 19, 2026 at 5:08 AM Jiri Pirko <jiri@resnulli.us> wrote:
> > > 
> > > Yeah, I was thinking about this and went back and forth. In the end, the
> > > only reason for leaving it unbounded is to allow multiple independent
> > > users of the same register. For example, IMA and systemd could share a
> > > TDX RTMR. The systemd side would read the journal through the
> > > attestation device and the IMA side through securityfs, but both are
> > > views of the same journal. If one side truncated it, the other could no
> > > longer replay the RTMR. Isn't this the valid usecase? Do you see how to
> > > resolve this?
> > > 
> > 
> > Bright minds have spent a significant amount of time working on this.
> > 
> > +Roberto Sassu, +Mimi Zohar
> 
> Dionna, thank you for including us in this discussion.
> 
> Based on my questioning AI, it sounds like the purpose of this patch set is to
> introduce a vendor-agnostic common attestation subsystem framework that can act
> as an internal kernel multiplexor for any measurement consumer, like IMA or
> DRTM. By providing a direct kernel-to-kernel call path, it allows measurements
> to be routed to different Roots of Trust (ROT)—such as physical motherboard
> TPMs, Intel TDX RTMRs, AMD SEV-SNP registers, and PCIe SPDM devices—without
> hardcoding IMA to specific device drivers.

Yeah, I would say that is the eventual goal, this patch series would
be the first small step along those lines

> To support this framework, IMA requires a strict, atomic execution sequence to
> maintain the Measure → Extend → Execute (Measure Before Use) guarantee. This
> initializes early during the late_initcall phase within the initramfs (via
> dracut).
> 
> If the new subsystem introduces a direct kernel-to-kernel multiplexing call
> path, how will it ensure the mandatory synchronous wait behavior when extending
> multiple hardware backends?

Everything has this 'measure before use' requirement. Why would this
be hard? Just loop over all the configured measurement targets if
thats the plan? Maybe I'm missing something?

Jason