[RFC][PATCH] ima: Add support for staging measurements for deletion
Roberto Sassu
roberto.sassu at huaweicloud.com
Thu Dec 11 15:24:38 UTC 2025
On Thu, 2025-12-11 at 15:50 +0100, Roberto Sassu wrote:
> On Thu, 2025-12-11 at 10:56 +0100, Roberto Sassu wrote:
> > On Wed, 2025-12-10 at 11:12 -0800, Gregory Lumen wrote:
> > > Roberto,
> > >
> > > The proposed approach appears to be workable. However, if our primary goal
> > > here is to enable UM to free kernel memory consumed by the IMA log with an
> > > absolute minimum of kernel functionality/change, then I would argue that
> > > the proposed Stage-then-delete approach still represents unnecessary
> > > complexity when compared to a trim-to-N solution. Specifically:
>
> The benefit of the Stage-then-delete is that you don't need to scan the
> IMA measurements list in advance to determine what to trim, you just
> trim everything by swapping list head (very fast) and then you can read
> and delete the measurements out of the hot path.
I forgot: I will also add in my patch the ability to stage and trim in
one step, to satisfy your use case.
Roberto
> [...]
>
> >
> > > - There exists a potential UM measurement-loss race condition introduced
> > > by the staging functionality that would not exist with a trim-to-N
> > > approach. (Occurs if a kexec call occurs after a UM agent has staged
> > > measurements for deletion, but has not completed copying them to
> > > userspace). This could be avoided by persisting staged measurements across
> > > kexec calls at the cost of making the proposed change larger.
> >
> > The solution is to coordinate the staging with kexec in user space.
>
> To avoid requiring coordination in user space, I will try to see if I
> could improve my patch to prepend the staged entries to the current
> measurement list, before serializing them for kexec().
>
> Roberto
More information about the Linux-security-module-archive
mailing list