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

[Mimi Zohar]

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.

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?

I strongly agree with Jason’s point that we should table any discussions
regarding a new dynamic log or uAPI additions at this stage, and focus strictly
on exposing the static firmware-level TDX log. I also echo Jiri’s concern that
replacing the securityfs template log with a placeholder string would break
backwards compatibility for the existing IMA ecosystem.

Thanks,

Mimi


> IMA logs and systemd logs are both system level concerns that are
> relevant to the OS construction, not individual users,
> so I would just say to reroute IMA to use ctlv using a kernel config
> setting, then make systemd the new system manager of the holistic log.


> The securityfs log contents can simply say, "log managed by ctlv" in
> this setting, in the form of the template identifier.
> For policy violations, only the 0... extend needs to go to ctlv.
> IMA can still keep its violation log as a ring buffer when it's not a
> 1-to-1 violation to extension