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

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

On Wed, 2025-12-17 at 10:26 -0500, Mimi Zohar wrote:
> Hi Roberto,
> 
> Thank you!  Everything is working as designed.
> 
> - Only public functions require kernel-doc comments, but other functions would
> benefit having a comment.
> 
> - As I mentioned in response to Steven's patch, "After trimming the measurement
> list, existing verifiers, which walk the IMA measurement list, will obviously
> fail to match the PCRs.  Breaking existing userspace applications is a problem
> and, unfortunately, requires yet another Kconfig option.  It needs to be at
> least mentioned here in the patch description."

Hi Mimi

sure.

> On Fri, 2025-12-12 at 18:19 +0100, Roberto Sassu 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. 
> 
> This last sentence is the crux of your of your proposal.
>  -> "quickly be atomically ... so ..."

Ok.

> I must be missing something.  With the ability of trimming N records, it's
> unclear to me the benefit of staging the measurement list and requiring a
> separate deletion. The measurement list can be read before trimming without
> loosing any measurements.  Like now, the entire measurement list could be moved
> to a staging area. Instead of freeing all of the records, only N records would
> be freed.  Afterwards the remaining staged measurements (N+1) could be restored
> to the head of the measurement list.

My hope is to avoid trimming based on N in the kernel, but rather offer
the same functionality on a user space service that simply gets all the
measurements it can from the kernel (with the stage all approach), and
exposes the desired measurements to requesting applications (based on N
or based on a PCR value, as Microsoft requested).

I think it was already mentioned earlier in the discussion. By reading
and trimming at two different times, there is a race window where two
separate remote attestation agents determine N on the current
measurements list and attempt to trim one after another with the same
N, but the latter attempts to do it on an already trimmed measurements
list. They could take the write lock for the read too to avoid that.

The stage all approach is not susceptible to this race window, because
it does not require a prior read before the operation.

Thanks

Roberto