Message-ID: <d736d6cf-4582-4b53-8b23-1a15bd2ec2f4@linux.microsoft.com>
Date: Thu, 11 Dec 2025 11:47:27 -0800
From: steven chen <chenste@...ux.microsoft.com>
To: Roberto Sassu <roberto.sassu@...weicloud.com>,
 Gregory Lumen <gregorylumen@...ux.microsoft.com>
Cc: corbet@....net, zohar@...ux.ibm.com, dmitry.kasatkin@...il.com,
 eric.snowberg@...cle.com, paul@...l-moore.com, jmorris@...ei.org,
 serge@...lyn.com, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-integrity@...r.kernel.org, linux-security-module@...r.kernel.org,
 nramas@...ux.microsoft.com, Roberto Sassu <roberto.sassu@...wei.com>,
 steven chen <chenste@...ux.microsoft.com>
Subject: Re: [RFC][PATCH] ima: Add support for staging measurements for
 deletion

On 12/11/2025 1:56 AM, 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:
>>
>> - Any functional benefit offered through the introduction of a staged
>> measurement list could be equally achieved in UM with a trim-to-N solution
>> coupled with the proposed ima_measure_users counter for access locking.
> Ok, let's quantify the complexity of each solution. Let's assume that
> the IMA measurements list has M entries and you want to trim at N < M.
>
> Staging:
>
> 1st. trim at N
>
> (kernel)
> 1. list lock (write side) -> list replace (swap the heads) -> list unlock
> 2. read M -> file (file contains 0..M)
> 3. for each 0..M -> delete entry
>
> (user)
> 1. for each 0..N in file -> replay PCR
> 2. trim at N (keep N + 1..M)
>
>
> 2nd. trim at O
>
> (kernel)
> 1. list lock -> list replace (swap the heads) -> list unlock
> 2. read P -> file (file contains N + 1..P)
> 3. for each M + 1..P -> delete entry
>
> (user)
> 1. for each N + 1..O in file -> replay PCR
> 2. trim at O (keep O + 1..P)
>
>
>
> Trimming:
>
> 1st. trim at N
>
> (kernel)
> 1. list lock (read side) -> for each 0..M -> read in file (file now contains 0..M) -> list unlock
>
> (user)
> 1. for each 0..N -> replay PCR
> 2. discard N + 1..M
>
> (kernel)
>
> 1. list lock (write side) -> for each 0..N -> trim -> list unlock
>
>
> 2nd. trim at O
>
> (kernel)
> 1. list lock (read side) -> for each N + 1..P -> read in file (file now contains N + 1..P) -> list unlock
>
> (user)
> 1. for each N + 1..O -> replay PCR
> 2. discard O + 1..P
>
> (kernel)
>
> 1. list lock (write side) -> for each N + 1..O -> trim -> list unlock
>
>
> You can try to optimize it a bit by prematurely ending the reading
> before M and P, and by replaying the PCR on a partial buffer.
>
>
> But still:
>
> I just swap list heads in the hot path (still need to do the same for
> the hash table, postponed to later), and do the free later once there
> is no contention with new measurements.
>
> In your case you are taking the lock and walking the list two times,
> once as a reader and once as a writer, and discarding measurements in
> user space that you already have.
>
> I think your solution is more complex.
This is not the case, please check the 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/20251210235314.3341-1-chenste@linux.microsoft.com/T/#t>


The following are the steps for trim N solution:
     User space reads list without lock
     User space decides to trim N entries and send command to kernel
     Kernel will lock the list use the same or less time as staged 
solution use

All work done.

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

Powered by blists - more mailing lists