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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8ef8a96eacbaa71f359ff800e7417ae565b95e81.camel@linux.ibm.com>
Date: Wed, 17 Dec 2025 14:41:01 -0500
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Roberto Sassu <roberto.sassu@...weicloud.com>, corbet@....net,
        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, 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 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@...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. 
> > 
> > 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