From: Breno Leitao <leitao@debian.org>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Roberto Sassu <roberto.sassu@huawei.com>,
Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
Eric Snowberg <eric.snowberg@oracle.com>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Andrew Morton <akpm@linux-foundation.org>,
Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, noodles@earth.li
Subject: Re: [PATCH] ima: kexec: Add RCU read lock protection for ima_measurements list traversal
Date: Wed, 20 Nov 2024 19:44:46 +0000 [thread overview]
Message-ID: <Zz48LjTS_r-j9Qny@gmail.com> (raw)
In-Reply-To: <b89a084a98e7427911ac4344225eca99a04a52fb.camel@linux.ibm.com>
Hello Mimi,
On Tue, Nov 19, 2024 at 01:10:10PM -0500, Mimi Zohar wrote:
> Hi Breno,
>
> On Mon, 2024-11-04 at 02:47 -0800, Breno Leitao wrote:
> > Fix a potential RCU issue where ima_measurements list is traversed using
> > list_for_each_entry_rcu() without proper RCU read lock protection. This
> > caused warnings when CONFIG_PROVE_RCU was enabled:
> >
> > security/integrity/ima/ima_kexec.c:40 RCU-list traversed in non-reader section!!
> >
> > Add rcu_read_lock() before iterating over ima_measurements list to ensure
> > proper RCU synchronization, consistent with other RCU list traversals in
> > the codebase.
>
> The synchronization is to prevent freeing of data while walking the RCU list. In
> this case, new measurements are only appended to the IMA measurement list. So
> there shouldn't be an issue.
>
> The IMA measurement list is being copied during kexec "load", while other
> processes are still running. Depending on the IMA policy, the kexec "load",
> itself, and these other processes may result in additional measurements, which
> should be copied across kexec. Adding the rcu_read_{lock, unlock} would
> unnecessarily prevent them from being copied.
Thank you for the detailed explanation. Since rcu_read_lock() operations are
lightweight, I believe keeping them wouldn't impact performance significantly.
However, if you prefer the lockless approach, I would suggest adding an
argument to list_for_each_entry_rcu() to keep the warning out. What are
your thoughts on this?
Author: Breno Leitao <leitao@debian.org>
Date: Mon Nov 4 02:26:45 2024 -0800
ima: kexec: silence RCU list traversal warning
The ima_measurements list is append-only and doesn't require rcu_read_lock()
protection. However, lockdep issues a warning when traversing RCU lists
without the read lock:
security/integrity/ima/ima_kexec.c:40 RCU-list traversed in non-reader section!!
Fix this by using the lockless variant of list_for_each_entry_rcu() with
the last argument set to true. This tells the RCU subsystem that
traversing this append-only list without the read lock is intentional
and safe.
This change silences the lockdep warning while maintaining the correct
semantics for the append-only list traversal.
Signed-off-by: Breno Leitao <leitao@debian.org>
diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
index 52e00332defed..9d45f4d26f731 100644
--- a/security/integrity/ima/ima_kexec.c
+++ b/security/integrity/ima/ima_kexec.c
@@ -37,7 +37,8 @@ static int ima_dump_measurement_list(unsigned long *buffer_size, void **buffer,
memset(&khdr, 0, sizeof(khdr));
khdr.version = 1;
- list_for_each_entry_rcu(qe, &ima_measurements, later) {
+ /* This is an append-only list, no need to hold the RCU read lock */
+ list_for_each_entry_rcu(qe, &ima_measurements, later, true) {
if (file.count < file.size) {
khdr.count++;
ima_measurements_show(&file, qe);
next prev parent reply other threads:[~2024-11-20 19:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-04 10:47 [PATCH] ima: kexec: Add RCU read lock protection for ima_measurements list traversal Breno Leitao
2024-11-19 18:10 ` Mimi Zohar
2024-11-20 19:44 ` Breno Leitao [this message]
2024-11-20 20:38 ` Mimi Zohar
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=Zz48LjTS_r-j9Qny@gmail.com \
--to=leitao@debian.org \
--cc=akpm@linux-foundation.org \
--cc=bauerman@linux.vnet.ibm.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=ebiederm@xmission.com \
--cc=eric.snowberg@oracle.com \
--cc=jmorris@namei.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=noodles@earth.li \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=zohar@linux.ibm.com \
--cc=zohar@linux.vnet.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