On 12/11/2025 7:24 AM, Roberto Sassu wrote:
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
Hi Roberto,
The below is what you want in one step. I think anything more than this
does not bring any extra value.
I released version 2 of trim N entries patch as bellow:
[PATCH v2 0/1] Trim N entries of IMA event logs
<https://lore.kernel.org/linux-integrity/[email protected]/T/#t>
Steven
[...]
- 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
