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

[Mimi Zohar <zohar@linux.ibm.com>]

On Wed, 2025-12-17 at 17:01 +0100, Roberto Sassu wrote:
> 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).

Agreed, the measurement list needs to be copied to userspace and saved.  How
userspace applications will access it needs to be defined and documented.

I thought Microsoft backed away from trimming the measurement list based on a
PCR value. At least basing it on a PCR value, is not implemented in the kernel.

> 
> 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.

Yes, I saw the problem in v1, when the second request wasn't rejected but was
synchronized by a mutex.  That should have been fixed in v2 with your locking
changes.

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

I'm not convinced of that, as any application with cap sysadmin can initiate a
trim or trim & delete.  At least at the moment, there's no way of limiting the
trim/delete to a given application.  Perhaps it could be limited based on
SELinux labels.

-- 
thanks,

Mimi