Message-ID: <877e2fec-febf-4568-9b00-059094d1c23b@linux.microsoft.com>
Date: Thu, 11 Dec 2025 14:06:50 -0800
From: steven chen <chenste@...ux.microsoft.com>
To: Roberto Sassu <roberto.sassu@...weicloud.com>, corbet@....net,
 zohar@...ux.ibm.com, dmitry.kasatkin@...il.com, eric.snowberg@...cle.com,
 paul@...l-moore.com, jmorris@...ei.org, serge@...lyn.com
Cc: linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-integrity@...r.kernel.org, linux-security-module@...r.kernel.org,
 gregorylumen@...ux.microsoft.com, 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 11:20 AM, steven chen wrote:
> On 12/11/2025 2:18 AM, Roberto Sassu wrote:
>> On Wed, 2025-12-10 at 16:03 -0800, steven chen wrote:
>>> On 12/9/2025 2:17 AM, Roberto Sassu wrote:
>>>> From: Roberto Sassu <roberto.sassu@...wei.com>
>>>>
>>>> Introduce the ability of staging the entire of the IMA measurement 
>>>> list, or
>>>> a portion, for deletion. Staging means moving the current content 
>>>> of the
>>>> measurement list to a separate location, and allowing users to read 
>>>> and
>>>> delete it. This causes the measurement list to be atomically truncated
>>>> before new measurements can be added. Staging can be done only once 
>>>> at a
>>>> time.
>>>>
>>>> User space is responsible to concatenate the staged IMA 
>>>> measurements list
>>>> portions following the temporal order in which the operations were 
>>>> done,
>>>> together with the current measurement list. Then, it can send the 
>>>> collected
>>>> data to the remote verifiers.
>>>>
>>>> The benefit of this solution is the ability to free precious kernel 
>>>> memory,
>>>> in exchange of delegating user space to reconstruct the full 
>>>> measurement
>>>> list from the chunks. No trust needs to be given to user space, 
>>>> since the
>>>> integrity of the measurement list is protected by the TPM.
>>>>
>>>> By default, staging the measurements list for deletion does not 
>>>> alter the
>>>> hash table. When staging is done, IMA is still able to detect 
>>>> collisions on
>>>> the staged and later deleted measurement entries, by keeping the entry
>>>> digests (only template data are freed).
>>>>
>>>> However, since during the measurements list serialization only the 
>>>> SHA1
>>>> digest is passed, and since there are no template data to 
>>>> recalculate the
>>>> other digests from, the hash table is currently not populated with 
>>>> digests
>>>> from staged/deleted entries after kexec().
>>>>
>>>> Introduce the new kernel option ima_flush_htable to decide whether 
>>>> or not
>>>> the digests of staged measurement entries are flushed from the hash 
>>>> table.
>>>>
>>>> Then, introduce ascii_runtime_measurements_staged_<algo> and
>>>> binary_runtime_measurement_staged_<algo> interfaces to stage/delete 
>>>> the
>>>> measurements. Use 'echo A > <IMA interface>' and 'echo D > <IMA 
>>>> interface>'
>>>> to respectively stage and delete the entire measurements list. Use
>>>> 'echo N > <IMA interface>', with N between 1 and ULONG_MAX, to 
>>>> stage the
>>>> selected portion of the measurements list.
>>>>
>>>> The ima_measure_users counter (protected by the ima_measure_lock 
>>>> mutex) has
>>>> been introduced to protect access to the measurement list and the 
>>>> staged
>>>> part. The open method of all the measurement interfaces has been 
>>>> extended
>>>> to allow only one writer at a time or, in alternative, multiple 
>>>> readers.
>>>> The write permission is used to stage/delete the measurements, the 
>>>> read
>>>> permission to read them. Write requires also the CAP_SYS_ADMIN 
>>>> capability.
>>> Hi Roberto,
>>>
>>> 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/20251210235314.3341-1-chenste@linux.microsoft.com/T/#t> 
>>>
>>>
>>> I adapted some of your idea and I think trim N has following 
>>> advantages:
>>> 1: less measurement list hold time than your current implementation
>>> 2. operation much simple for user space
>>> 3. less kernel code change
>>> 4. no potential issue as Gregory mentioned.
>> Please have a look at:
>>
>> https://marc.info/?l=linux-integrity&m=176545085325473&w=2
>>
>> and let me know if I'm missing something.
>>
>> Thanks
>>
>> Roberto
>
> Hi Roberto,
>
> what does this staging solution do that's not achieved by trim N 
> entries solution?
>
> You did not address all my comments and your other idea make things 
> more complex.

The following are steps for both proposals:

     the steps for trim N solution:
         1. User space reads list without lock
         2. User space decides to trim N entries and send command to kernel
         3. Kernel will lock the list use the same or less time as 
staged solution use(we can improve this together)

     the steps for staged N solution:
         1. User space reads list without lock
         2. User space stages list with lock
         3. User space decides to trim N entries and send command to kernel
         4. Kernel trim staged list (staged list may not empty after trim)
         5. kexec save the staged list during soft reboot
         6. kexec restore the staged list during soft reboot

>
> Also, Trim N solution is simple and will bring following two good points:
>     easy for future IMA development
will be easier for future "Kexec Measurement List Passing" project
> easy for code maintenance
>
> Could you also add your comments on the trim N solution?
>
> Thanks,
>
> Steven
>
>>
>>> Thanks,
>>>
>>> Steven 

Powered by blists - more mailing lists