[PATCH v3 3/3] ima: Add support for staging measurements for deletion

steven chen chenste at linux.microsoft.com
Fri Mar 20 17:24:37 UTC 2026


On 3/20/2026 10:10 AM, Roberto Sassu wrote:
> On Fri, 2026-03-20 at 09:58 -0700, steven chen wrote:
>> On 3/20/2026 5:41 AM, Mimi Zohar wrote:
>>> On Thu, 2026-03-19 at 14:31 -0700, steven chen wrote:
>>>
>>>>> - Support for deleting N measurement records (and pre-pending the remaining
>>>>> measurement records)
>>>> Is there any problem to bring work of "stage" step together to the
>>>> deletion step?
>>>>
>>>> "Trim N" method does everything that "staged" method can do, right?
>>>> what's the "stage" method can do but "trim N" method can't do?
>>>>
>>>> in user space, if in "staged" state, no other user space agent can
>>>> access the IMA measure list, right?
>>>>
>>>> Could you explain the benefit of bringing the "stage" step?
>>> The performance improvement is because "staging" the IMA measurement list takes
>>> the lock in order to move the measurement list pointer and then releases it.
>>> New measurements can then be appended to a new measurement list.  Deleting
>>> records is done without taking the lock to walk the staged measurement list.
>>>
>>> Without staging the measurement list, walking the measurement list to trim N
>>> records requires taking and holding the lock.  The performance is dependent on
>>> the size of the measurement list.
>>>
>>> Your question isn't really about "staging" the measurement list records, but
>>> requiring a userspace signal to delete them.  To answer that question, deleting
>>> N records (third patch) could imply staging all the measurement records and
>>> immediately deleting N records without an explicit userspace signal.
>>>
>>> I expect the requested "documentation" patch will provide the motivation for the
>>> delayed deletion of the measurement list.
>>>
>>> Mimi
>> "Staging" is great on reducing kernel IMA measurement list locking time.
>>
>> How about just do "stage N" entries and then delete the staged list in
>> one shot?
>> It means merge two APIs into one API
>>       int ima_queue_stage(void)
>>       int ima_queue_delete_staged(unsigned long req_value)
>>
>> The kernel lock time will be the same. And user space lock time will be
>> reduced.
> It is not the same. The walk on the staged list is done without holding
> ima_extend_list_mutex.
>
> Roberto

Is it possible to merge two APIs work into one API?
      int ima_queue_stage(void)
      int ima_queue_delete_staged(unsigned long req_value)

Thank,

Steven




More information about the Linux-security-module-archive mailing list