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

[Mimi Zohar]

On Wed, 2026-10-21 at 10:33 +0200, Jiri Pirko wrote:
> Tue, Oct 20, 2026 at 12:56:58AM +0200, jgg@xxxxxxxxxx wrote:
> > On Mon, Oct 19, 2026 at 09:10:31AM -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
> > > 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
> > > https://www.youtube.com/watch?v=gyYUYbdiN_4
> > 
> > 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.

Mimi