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
