[PATCH 1/1] IMA event log trimming

[James Bottomley]

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.

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

Regards,

James