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

[Yeoreum Yun]

Hi,

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

But, I have a related concern about deferred probing of RoT devices.

For example, if TPM probing is deferred until after the attestation
subsystem has been initialized, how would the subsystem handle the
TPM becoming available later (This is reason for IMA_INIT_LATE_SYNC).

In particular, when I see breifly proviers/tdx.c and imange for TPM,
once if it's failed to get tpm_default_chip() in module_init(),
There is no way to retry and TPM seems not to be exported as RoT device.

Am I missing something?

-- 
Sincerely,
Yeoreum Yun