Re: [PATCH 1/1] IMA event log trimming

[Roberto Sassu <roberto.sassu@huaweicloud.com>]

On Tue, 2025-12-09 at 07:17 +0900, James Bottomley wrote:
> On Mon, 2025-12-08 at 10:40 +0100, Roberto Sassu wrote:
> > I have the impression that none the functionality you cited has to be
> > implemented in the kernel, because the only component one can trust
> > to verify the integrity of the IMA measurements list is the TPM.
> > Whether either the kernel or user space retain the measurements is
> > irrelevant.
> 
> That's correct, I'm not advocating moving quoting into the kernel.  Co-
> ordinating the trim with where the quote gets you to is phenomenally
> useful.  While you could theoretically store any mismatch in userspace,
> having two locations for the log makes it more error prone.
> 
> > I believe that the only role of the kernel is to get rid of the
> > measurements entries as fast as possible (the kernel would act more
> > like a buffer).
> 
> I wouldn't say that, I'd say to get rid of measurements that the user
> has indicated are of no further use.

Different users could have different and conflicting requirements, and
we would spend time trying to conciliate those. We can avoid that by
doing it the same for everyone, and the additional cost of handling it
I believe it is fair.

I could accept staging N entries since I already agreed with Gregory
and Steven, and since it requires only an extra iteration in the linked
list. The other desired functionality should be implemented in user
space.

> > This was actually the intent of my original proposal in
> > https://github.com/linux-integrity/linux/issues/1 . The idea of
> > staging (was snapshotting, but Mimi thinks the term is not accurate)
> > is simply to detach the entire IMA measurement list as fast as
> > possible. Further read and delete after staging is done without
> > interfering with new measurements (sure, the detaching of the hash
> > table is not yet as efficient as I hoped).
> 
> From the application point of view, offloading the log and random
> points is a bit more work because now the log collector has to be
> modified to look in multiple locations and we'd also need an agreement
> of where those locations are and how the log is sequenced in a naming
> scheme so it's the same for every distribution.  If the application is
> in charge of trimming the log at a particular point, collection remains
> the same (it can simply be the existing in-kernel location), so we
> don't need a cross distro agreement, and the trim can simply be added
> as an extra function.

It could be a single location, the user space program would be
responsible to present the IMA measurement list as if it was never
trimmed.

Roberto