From: Gregory Lumen <gregorylumen@linux.microsoft.com>
To: Roberto Sassu <roberto.sassu@huaweicloud.com>
Cc: corbet@lwn.net, zohar@linux.ibm.com, dmitry.kasatkin@gmail.com,
eric.snowberg@oracle.com, paul@paul-moore.com,
jmorris@namei.org, serge@hallyn.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
chenste@linux.microsoft.com, nramas@linux.microsoft.com,
Roberto Sassu <roberto.sassu@huawei.com>
Subject: Re: [RFC][PATCH] ima: Add support for staging measurements for deletion
Date: Wed, 10 Dec 2025 11:12:58 -0800 (PST) [thread overview]
Message-ID: <207fd6d7-53c-57bb-36d8-13a0902052d1@linux.microsoft.com> (raw)
In-Reply-To: <20251209101725.3680225-1-roberto.sassu@huaweicloud.com>
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:
- Any functional benefit offered through the introduction of a staged
measurement list could be equally achieved in UM with a trim-to-N solution
coupled with the proposed ima_measure_users counter for access locking.
- 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.
Thanks,
-Gregory Lumen
next prev parent reply other threads:[~2025-12-10 19:12 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-09 10:17 [RFC][PATCH] ima: Add support for staging measurements for deletion Roberto Sassu
2025-12-10 19:12 ` Gregory Lumen [this message]
2025-12-11 9:56 ` Roberto Sassu
2025-12-11 14:50 ` Roberto Sassu
2025-12-11 15:24 ` Roberto Sassu
2025-12-11 18:06 ` steven chen
2025-12-11 23:38 ` steven chen
2025-12-11 19:47 ` steven chen
2025-12-11 0:03 ` steven chen
2025-12-11 10:18 ` Roberto Sassu
2025-12-11 19:20 ` steven chen
2025-12-11 22:06 ` steven chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=207fd6d7-53c-57bb-36d8-13a0902052d1@linux.microsoft.com \
--to=gregorylumen@linux.microsoft.com \
--cc=chenste@linux.microsoft.com \
--cc=corbet@lwn.net \
--cc=dmitry.kasatkin@gmail.com \
--cc=eric.snowberg@oracle.com \
--cc=jmorris@namei.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=nramas@linux.microsoft.com \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=roberto.sassu@huaweicloud.com \
--cc=serge@hallyn.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).