Re: [RFC][PATCH v2] ima: Add support for staging measurements for deletion and trimming

[Roberto Sassu <roberto.sassu@huaweicloud.com>]

On Fri, 2025-12-12 at 21:06 -0500, Paul Moore wrote:
> On Fri, Dec 12, 2025 at 12:19 PM Roberto Sassu
> <roberto.sassu@huaweicloud.com> wrote:
> > From: Roberto Sassu <roberto.sassu@huawei.com>
> > 
> > Introduce the ability of staging the entire (or a portion of the) IMA
> > measurement list 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. In the event of kexec(), staging is reverted and staged entries will
> > be carried over to the new kernel.
> > 
> > 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.
> > 
> > Also introduce the ability of trimming N measurements entries from the IMA
> > measurements list, provided that user space has already read them. Trimming
> > combines staging and deletion in one operation.
> > 
> > The benefit of these solutions 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/trimming the measurements list does not alter the hash
> > table. When staging/trimming are 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/trim/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
> > LONG_MAX, to stage the selected portion of the measurements list, and
> > 'echo -N > <IMA interface>' to trim N measurements entries.
> 
> In an effort to help preserve the sanity of admins, I might suggest
> avoiding commands that start with a dash/'-'.  I'd probably also
> simplify the commands a bit and drop all/'A' since the measurement
> list could change at any time, stick with an explicit number and just
> let the admin go over, e.g. write LONG_MAX, which effectively becomes
> 'A'.  I think you could do everything you need with just two commands:
> 
>   <NUM>: stage <NUM> entries
>       D: delete staged entries

If the goal is that the verifier always receives a TPM quote aligned
with the measurements, the remote attestation agent in the target
system has to walk over the measurements to find N.

The difference between the approach I was suggesting and Steven's is
that I calculate N after staging all measurements and store the
exceeding measurements locally until the next attestation request. If
the verifier supports it, the exceeding measurements could be stored
also there.

That means that I don't need to walk in the measurement list to stage,
because I stage the entire list (with list_replace()). I do a walk
after detaching, without interfering with the processes adding new
measurements (hot path).

Steven's approach is to read the measurements list to calculate N and
stage/trim the measurement based on N. As Steven/Gregory pointed out,
at this point you could already trim N because you already have the
measurements list.

However, in this case you have to walk through the measurements list as
an RCU reader in the hot path, calculate N, and walk through the
measurements list again as an RCU writer in the hot path to stage/trim
N. In the next attestation request, you would read the previous
exceeding measurements again.

One major obstacle of my approach, as Gregory pointed out, was that
staged measurements were not carried over during kexec(). While I
thought about coordinating remote attestation requests with kexec() in
a management engine, there can be cases where this is harder to
achieve.

I managed to solve that by introducing a third linked list containing
the measurements to delete, by doing another list replace between
staged and measurements to delete (when the 'D' command is issued),
under the hot path lock. That allowed me to take the hot path lock
during kexec() and prepend the staged measurements before the non-
staged ones (that reminded me that I should properly inform user space 
if kexec() consumed staged measurements before the 'D' command was
executed, i.e. it lost the race with kexec()).

The approach to keep the stage N approach would be necessary if
exceeding measurements cannot be stored either locally or at the
verifier side.

For me it would be fine to keep both approaches, but I still see
advantages of the stage all approach.

Thanks

Roberto

> I intentionally left out the trim/'T' command, because I'm not sure it
> is really necessary if you are going to implement the phased
> stage/delete process.  Yes, you have to do two operations (stage and
> delete) as opposed to just the trim, but I'd probably take the
> simplicity of just supporting a single approach over the trivial
> necessity of having to do two operations in userspace.
> 
> Staging also has the benefit of having a sane way of handling two
> tasks racing to stage the measurement list.  I could see cases where
> multiple tasks race to trim the list and end up trimming more than was
> intended since they both hit in sequence.
> 
> If you did want to take a trim approach over a stage/delete approach,
> I could see something like this working:
> 
>  1. process opens the measurement list
>  2. process reads from the measurement list, keeps the fd open
>  3. process does whatever it wants to preserve the list
>  4. process writes <NUM> to the measurement list, kernel trims <NUM> entries
>  5. process closes fd
> 
> ... error handling shouldn't be too bad.  The process only writes
> <NUM> to the fd if it has already finished whatever it needs to do to
> preserve the list outside the kernel, think of it as a "commit"
> operation on a transaction.  If the fd is closed for some reason
> (error, interruption, killed) before the process writes <NUM> to the
> fd then IMA does nothing - no trim takes place.
> 
> Multiple process racing can easily be solved when the log is opened;
> only one open(O_RDWR) is allowed at a time, other racing processes
> will get EBUSY.  Yes, one process could block others from trimming by
> holding the fd open for an extended period of time, but I would expect
> that CAP_SYS_ADMIN and root fs perms would be required to open the log
> read/write (not to mention any LSM access rights in place).
> 
> I know I mentioned this basic idea to someone at some point, but there
> have been various discussion threads and multiple people over a fairly
> lengthy time that I've lost track of where it was mentioned.  If it
> was already discussed on-list and rejected for a good reason you can
> simply ignore the above approach ... although I still think the
> stage/delete API could be simplified as described :)
> 
> [UPDATE: as I'm reading Steven's replies it looks like he has proposed
> something very similar to the above]
>