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: <2f550d4cd860022e990d1de62049df85a6a86df8.camel@huaweicloud.com>
Date: Thu, 11 Dec 2025 15:50:22 +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 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.

[...]

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