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

[Mimi Zohar]

On Tue, 2026-10-20 at 11:06 -0300, Jason Gunthorpe wrote:
> 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@xxxxxxxxxxx> 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?

As long as the measurements aren't queued, but actually wait for the multiple
ROTs to complete, it isn't a problem.

Mimi