Message-ID: <CAHC9VhRUQxayj=XcdfbfHka-=N+B8cNk7Grg3QWGOTOz3BKfgw@mail.gmail.com>
Date: Fri, 12 Dec 2025 21:06:50 -0500
From: Paul Moore <paul@...l-moore.com>
To: Roberto Sassu <roberto.sassu@...weicloud.com>
Cc: corbet@....net, zohar@...ux.ibm.com, dmitry.kasatkin@...il.com, 
	eric.snowberg@...cle.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, 
	gregorylumen@...ux.microsoft.com, chenste@...ux.microsoft.com, 
	nramas@...ux.microsoft.com, Roberto Sassu <roberto.sassu@...wei.com>
Subject: Re: [RFC][PATCH v2] ima: Add support for staging measurements for
 deletion and trimming

On Fri, Dec 12, 2025 at 12:19 PM Roberto Sassu
<roberto.sassu@...weicloud.com> wrote:
> From: Roberto Sassu <roberto.sassu@...wei.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

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]

-- 
paul-moore.com

Powered by blists - more mailing lists