From: Mimi Zohar <zohar@linux.ibm.com>
To: Jonathan McDowell <noodles@earth.li>,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Cc: paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com,
roberto.sassu@huawei.com, dmitry.kasatkin@gmail.com,
eric.snowberg@oracle.com, jarkko@kernel.org, jgg@ziepe.ca,
sudeep.holla@kernel.org, maz@kernel.org, oupton@kernel.org,
joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com,
catalin.marinas@arm.com, will@kernel.org, noodles@meta.com,
sebastianene@google.com, Yeoreum Yun <yeoreum.yun@arm.com>
Subject: [PATCH] ima: debugging late_initcall_sync measurements
Date: Wed, 29 Apr 2026 16:01:12 -0400 [thread overview]
Message-ID: <7734099f5e7fda5480bca016a9e6707983325fbd.camel@linux.ibm.com> (raw)
In-Reply-To: <cover.1777036497.git.noodles@meta.com>
With this "[RFC PATCH v3 0/4] Fix IMA + TPM initialisation ordering
issue" patch set, how many records would be missing if IMA
initialization is deferred to late_initcall_sync [1]?
[1]https://lore.kernel.org/linux-integrity/cover.1777036497.git.noodles@meta.com/
---
Jonathan, Yeoreum, others -
By going into TPM-bypass mode, we can see how many measurements are actually
missing when deferring IMA initialization to late_initcall_sync. As this is
system/TPM dependent, I'd appreciate your checking. Please use the boot command
line option "ima_policy=tcb|critical_data".
thanks, Mimi
security/integrity/ima/ima.h | 1 +
security/integrity/ima/ima_init.c | 6 ++++++
security/integrity/ima/ima_main.c | 19 +++++++++++++++++++
3 files changed, 26 insertions(+)
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 01aae19ed365..9a1117112fb2 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -286,6 +286,7 @@ extern bool ima_canonical_fmt;
/* Internal IMA function definitions */
int ima_init_core(bool late);
+int ima_init_debug(bool late);
int ima_fs_init(void);
int ima_add_template_entry(struct ima_template_entry *entry, int violation,
const char *op, struct inode *inode,
diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c
index 5f335834a9bb..edd063b99685 100644
--- a/security/integrity/ima/ima_init.c
+++ b/security/integrity/ima/ima_init.c
@@ -122,6 +122,12 @@ void __init ima_load_x509(void)
}
#endif
+int __init ima_init_debug(bool late)
+{
+ ima_add_boot_aggregate(late); /* just add an additional record */
+ return 0;
+}
+
int __init ima_init_core(bool late)
{
int rc;
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 42099bfe7e43..23e669be54fc 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -1254,6 +1254,7 @@ static int ima_kernel_module_request(char *kmod_name)
#endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
+#define TESTING 1
static int __init init_ima(bool late)
{
int error;
@@ -1264,6 +1265,23 @@ static int __init init_ima(bool late)
return 0;
}
+#ifdef TESTING
+ /*
+ * Initialize early, even if it means going into TPM-bypass mode,
+ * but add an additional boot_aggregrate message for the
+ * late_initcall_sync.
+ *
+ * If measurement list records exist between the boot_aggregate
+ * and the boot_aggregate_late records, these records would be
+ * missing when IMA initializion is deferred to late_initcall_sync.
+ */
+ if (ima_tpm_chip) {
+ ima_init_debug(late); /* Add an additional record */
+ return 0;
+ }
+
+ ima_tpm_chip = tpm_default_chip();
+#elif
/*
* If we found the TPM during our first attempt, or we know there's no
* TPM, nothing further to do
@@ -1276,6 +1294,7 @@ static int __init init_ima(bool late)
pr_debug("TPM not available, will try later\n");
return -EPROBE_DEFER;
}
+#endif
if (!ima_tpm_chip)
pr_info("No TPM chip found, activating TPM-bypass!\n");
--
2.53.0
prev parent reply other threads:[~2026-04-29 20:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-24 13:23 [RFC PATCH v3 0/4] Fix IMA + TPM initialisation ordering issue Jonathan McDowell
2026-04-24 13:24 ` [RFC PATCH v3 1/4] lsm: Allow LSMs to register for late_initcall_sync init Jonathan McDowell
2026-04-24 13:24 ` [RFC PATCH v3 2/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM Jonathan McDowell
2026-04-24 16:55 ` Yeoreum Yun
2026-04-24 20:25 ` Mimi Zohar
2026-04-25 9:10 ` Jonathan McDowell
2026-04-24 13:24 ` [RFC PATCH v3 3/4] Revert "tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in" Jonathan McDowell
2026-04-24 16:10 ` Sudeep Holla
2026-04-24 13:24 ` [RFC PATCH v3 4/4] Revert "firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall" Jonathan McDowell
2026-04-24 16:09 ` Sudeep Holla
2026-04-25 14:19 ` Jarkko Sakkinen
2026-04-29 20:01 ` Mimi Zohar [this message]
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=7734099f5e7fda5480bca016a9e6707983325fbd.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=eric.snowberg@oracle.com \
--cc=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=jmorris@namei.org \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=maz@kernel.org \
--cc=noodles@earth.li \
--cc=noodles@meta.com \
--cc=oupton@kernel.org \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=sebastianene@google.com \
--cc=serge@hallyn.com \
--cc=sudeep.holla@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yeoreum.yun@arm.com \
--cc=yuzenghui@huawei.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