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

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <75d8b82a2e493ca919926310c5f381221555d82d.camel@huaweicloud.com>
Date: Thu, 11 Dec 2025 16:24:38 +0100
From: Roberto Sassu <roberto.sassu@...weicloud.com>
To: Gregory Lumen <gregorylumen@...ux.microsoft.com>
Cc: corbet@....net, zohar@...ux.ibm.com, dmitry.kasatkin@...il.com, 
 eric.snowberg@...cle.com, paul@...l-moore.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, 
 chenste@...ux.microsoft.com, nramas@...ux.microsoft.com, Roberto Sassu
 <roberto.sassu@...wei.com>
Subject: Re: [RFC][PATCH] ima: Add support for staging measurements for
 deletion

On Thu, 2025-12-11 at 15:50 +0100, Roberto Sassu wrote:
> On Thu, 2025-12-11 at 10:56 +0100, Roberto Sassu wrote:
> > On Wed, 2025-12-10 at 11:12 -0800, Gregory Lumen wrote:
> > > Roberto,
> > > 
> > > The proposed approach appears to be workable. However, if our primary goal 
> > > here is to enable UM to free kernel memory consumed by the IMA log with an 
> > > absolute minimum of kernel functionality/change, then I would argue that 
> > > the proposed Stage-then-delete approach still represents unnecessary 
> > > complexity when compared to a trim-to-N solution. Specifically:
> 
> The benefit of the Stage-then-delete is that you don't need to scan the
> IMA measurements list in advance to determine what to trim, you just
> trim everything by swapping list head (very fast) and then you can read
> and delete the measurements out of the hot path.

I forgot: I will also add in my patch the ability to stage and trim in
one step, to satisfy your use case.

Roberto

> [...]
> 
> > 
> > > - There exists a potential UM measurement-loss race condition introduced 
> > > by the staging functionality that would not exist with a trim-to-N 
> > > approach. (Occurs if a kexec call occurs after a UM agent has staged 
> > > measurements for deletion, but has not completed copying them to 
> > > userspace). This could be avoided by persisting staged measurements across 
> > > kexec calls at the cost of making the proposed change larger.
> > 
> > The solution is to coordinate the staging with kexec in user space.
> 
> To avoid requiring coordination in user space, I will try to see if I
> could improve my patch to prepend the staged entries to the current
> measurement list, before serializing them for kexec().
> 
> Roberto