Fix IMA + TPM initialisation ordering issue

From: Jonathan McDowell <[email protected]>

The Linux IMA (Integrity Measurement Architecture) subsystem used for secure boot, file integrity, or remote attestation cannot be a loadable module for few reasons listed below:

o Boot-Time Integrity: IMA’s main role is to measure and appraise files before they are used. This includes measuring critical system files during early boot (e.g., init, init scripts, login binaries). If IMA were a module, it would be loaded too late to cover those.

o TPM Dependency: IMA integrates tightly with the TPM to record measurements into PCRs. The TPM must be initialized early (ideally before init_ima()), which aligns with IMA being built-in.

o Security Model: IMA is part of a Trusted Computing Base (TCB). Making it a module would weaken the security model, as a potentially compromised system could delay or tamper with its initialization.

IMA must be built-in to ensure it starts measuring from the earliest possible point in boot which inturn implies TPM must be initialised and ready to use before IMA.

Unfortunately some TPM drivers (such as Arm FF-A, or SPI attached TPM devices) are not reliably available during the initcall_late stage, resulting in a log error:

ima: No TPM chip found, activating TPM-bypass!

and no measurements into the TPM by IMA. We can avoid this by doing IMA init in the initcall_late_sync stage, after the drivers have completed their init + registration.

Rather than do this everywhere, and needlessly delay the initialisation of IMA when there is no need to do so, we continue to try to initialise at the earlier stage, only deferring to the later point if the TPM is not available yet.

Signed-off-by Jonathan McDowell <[email protected]>

---
 security/integrity/ima/ima.h              |  3 +-
 security/integrity/ima/ima_init.c         | 25 ++++++++-------
 security/integrity/ima/ima_main.c         | 37 ++++++++++++++++++++---
 security/integrity/ima/ima_template_lib.c |  3 +-
 4 files changed, 50 insertions(+), 18 deletions(-)

security/integrity/ima/ima.h +2 -1

index 89ebe98ffc5e..b3677b403a5a 100644
@@ -65,6 +65,7 @@ extern struct ima_algo_desc *ima_algo_array __ro_after_init;
 extern int ima_appraise;
 extern struct tpm_chip *ima_tpm_chip;
 extern const char boot_aggregate_name[];
+extern const char boot_aggregate_late_name[];
 
 /* IMA event related data */
 struct ima_event_data {

@@ -257,7 +258,7 @@ static inline void ima_measure_kexec_event(const char *event_name) {}
 extern bool ima_canonical_fmt;
 
 /* Internal IMA function definitions */
-int ima_init(void);
+int ima_init_core(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,

security/integrity/ima/ima_init.c +14 -11

index a2f34f2d8ad7..5f335834a9bb 100644
@@ -22,6 +22,7 @@
 
 /* name for boot aggregate entry */
 const char boot_aggregate_name[] = "boot_aggregate";
+const char boot_aggregate_late_name[] = "boot_aggregate_late";
 struct tpm_chip *ima_tpm_chip;
 
 /* Add the boot aggregate to the IMA measurement list and extend

@@ -39,17 +40,17 @@ struct tpm_chip *ima_tpm_chip;
  * a different value.) Violations add a zero entry to the measurement
  * list and extend the aggregate PCR value with ff...ff's.
  */
-static int __init ima_add_boot_aggregate(void)
+static int __init ima_add_boot_aggregate(bool late)
 {
 	static const char op[] = "add_boot_aggregate";
 	const char *audit_cause = "ENOMEM";
 	struct ima_template_entry *entry;
 	struct ima_iint_cache tmp_iint, *iint = &tmp_iint;
-	struct ima_event_data event_data = { .iint = iint,
-					     .filename = boot_aggregate_name };
+	struct ima_event_data event_data = { .iint = iint };
 	struct ima_max_digest_data hash;
 	struct ima_digest_data *hash_hdr = container_of(&hash.hdr,
 						struct ima_digest_data, hdr);
+	const char *filename;
 	int result = -ENOMEM;
 	int violation = 0;
 

@@ -59,6 +60,12 @@ static int __init ima_add_boot_aggregate(void)
 	iint->ima_hash->algo = ima_hash_algo;
 	iint->ima_hash->length = hash_digest_size[ima_hash_algo];
 
+	if (late)
+		filename = boot_aggregate_late_name;
+	else
+		filename = boot_aggregate_name;
+	event_data.filename = filename;
+
 	/*
 	 * With TPM 2.0 hash agility, TPM chips could support multiple TPM
 	 * PCR banks, allowing firmware to configure and enable different

@@ -86,7 +93,7 @@ static int __init ima_add_boot_aggregate(void)
 	}
 
 	result = ima_store_template(entry, violation, NULL,
-				    boot_aggregate_name,
+				    filename,
 				    CONFIG_IMA_MEASURE_PCR_IDX);
 	if (result < 0) {
 		ima_free_template_entry(entry);

@@ -95,7 +102,7 @@ static int __init ima_add_boot_aggregate(void)
 	}
 	return 0;
 err_out:
-	integrity_audit_msg(AUDIT_INTEGRITY_PCR, NULL, boot_aggregate_name, op,
+	integrity_audit_msg(AUDIT_INTEGRITY_PCR, NULL, filename, op,
 			    audit_cause, result, 0);
 	return result;
 }

@@ -115,14 +122,10 @@ void __init ima_load_x509(void)
 }
 #endif
 
-int __init ima_init(void)
+int __init ima_init_core(bool late)
 {
 	int rc;
 
-	ima_tpm_chip = tpm_default_chip();
-	if (!ima_tpm_chip)
-		pr_info("No TPM chip found, activating TPM-bypass!\n");
-
 	rc = integrity_init_keyring(INTEGRITY_KEYRING_IMA);
 	if (rc)
 		return rc;

@@ -140,7 +143,7 @@ int __init ima_init(void)
 	rc = ima_init_digests();
 	if (rc != 0)
 		return rc;
-	rc = ima_add_boot_aggregate();	/* boot aggregate must be first entry */
+	rc = ima_add_boot_aggregate(late);	/* boot aggregate must be first entry */
 	if (rc != 0)
 		return rc;
 

security/integrity/ima/ima_main.c +32 -5

index 1d6229b156fb..0b93a286c0d3 100644
@@ -1237,7 +1237,7 @@ static int ima_kernel_module_request(char *kmod_name)
 
 #endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
 
-static int __init init_ima(void)
+static int __init init_ima(bool late)
 {
 	int error;
 

@@ -1247,10 +1247,26 @@ static int __init init_ima(void)
 		return 0;
 	}
 
+	/*
+	 * If we found the TPM during our first attempt, or we know there's no
+	 * TPM, nothing further to do
+	 */
+	if (late && (ima_tpm_chip || !IS_ENABLED(CONFIG_TCG_TPM)))
+		return 0;
+
+	ima_tpm_chip = tpm_default_chip();
+	if (!ima_tpm_chip && !late && IS_ENABLED(CONFIG_TCG_TPM)) {
+		pr_debug("TPM not available, will try later\n");
+		return -EPROBE_DEFER;
+	}
+
+	if (!ima_tpm_chip)
+		pr_info("No TPM chip found, activating TPM-bypass!\n");
+
 	ima_appraise_parse_cmdline();
 	ima_init_template_list();
 	hash_setup(CONFIG_IMA_DEFAULT_HASH);
-	error = ima_init();
+	error = ima_init_core(late);
 
 	if (error && strcmp(hash_algo_name[ima_hash_algo],
 			    CONFIG_IMA_DEFAULT_HASH) != 0) {

@@ -1258,7 +1274,7 @@ static int __init init_ima(void)
 			hash_algo_name[ima_hash_algo], CONFIG_IMA_DEFAULT_HASH);
 		hash_setup_done = 0;
 		hash_setup(CONFIG_IMA_DEFAULT_HASH);
-		error = ima_init();
+		error = ima_init_core(late);
 	}
 
 	if (error)

@@ -1274,6 +1290,16 @@ static int __init init_ima(void)
 	return error;
 }
 
+static int __init init_ima_late(void)
+{
+	return init_ima(false);
+}
+
+static int __init init_ima_late_sync(void)
+{
+	return init_ima(true);
+}
+
 static struct security_hook_list ima_hooks[] __ro_after_init = {
 	LSM_HOOK_INIT(bprm_check_security, ima_bprm_check),
 	LSM_HOOK_INIT(bprm_creds_for_exec, ima_bprm_creds_for_exec),

@@ -1319,6 +1345,7 @@ DEFINE_LSM(ima) = {
 	.init = init_ima_lsm,
 	.order = LSM_ORDER_LAST,
 	.blobs = &ima_blob_sizes,
-	/* Start IMA after the TPM is available */
-	.initcall_late = init_ima,
+	/* Ensure we start IMA after the TPM is available */
+	.initcall_late = init_ima_late,
+	.initcall_late_sync = init_ima_late_sync,
 };

security/integrity/ima/ima_template_lib.c +2 -2

index 0e627eac9c33..8a89236f926c 100644
@@ -363,7 +363,8 @@ int ima_eventdigest_init(struct ima_event_data *event_data,
 		goto out;
 	}
 
-	if ((const char *)event_data->filename == boot_aggregate_name) {
+	if ((const char *)event_data->filename == boot_aggregate_name ||
+	    (const char *)event_data->filename == boot_aggregate_late_name) {
 		if (ima_tpm_chip) {
 			hash.hdr.algo = HASH_ALGO_SHA1;
 			result = ima_calc_boot_aggregate(hash_hdr);
--

2.53.0

security/integrity/ima/ima_main.c +12 -0

+	if (late && (ima_tpm_chip || !IS_ENABLED(CONFIG_TCG_TPM)))
+		return 0;
+
+	ima_tpm_chip = tpm_default_chip();
+	if (!ima_tpm_chip && !late && IS_ENABLED(CONFIG_TCG_TPM)) {
+		pr_debug("TPM not available, will try later\n");
+		return -EPROBE_DEFER;
+	}
+
+	if (!ima_tpm_chip)
+		pr_info("No TPM chip found, activating TPM-bypass!\n");
+

Thanks, Jonathan!

Quoted 9 lines · Jonathan McDowell

security/integrity/ima/ima_main.c +1 -1

-static int __init init_ima(void)
+static int __init init_ima(bool late)

 {
  int error;

(quoted diff) +0 -0

@@ -1247,10 +1247,26 @@ static int __init init_ima(void)
  		return 0;
  	}

security/integrity/ima/ima_main.c static int __init init_ima(void) · line 1253

Quoted 4 lines

security/integrity/ima/ima_main.c +4 -0

+	/*
+	 * If we found the TPM during our first attempt, or we know there's no
+	 * TPM, nothing further to do
+	 */

Perhaps it's just me, but the comment wording is a bit off. Could I change it
to: If we either found the TPM or knew there's no TPM during our first attempt, nothing futher to do.

Otherwise the patch looks good.

Mimi

security/integrity/ima/ima_main.c static int __init init_ima(void) · line 1265

Quoted 12 lines

security/integrity/ima/ima_main.c +12 -0

+	if (late && (ima_tpm_chip || !IS_ENABLED(CONFIG_TCG_TPM)))
+		return 0;
+
+	ima_tpm_chip = tpm_default_chip();
+	if (!ima_tpm_chip && !late && IS_ENABLED(CONFIG_TCG_TPM)) {
+		pr_debug("TPM not available, will try later\n");
+		return -EPROBE_DEFER;
+	}
+
+	if (!ima_tpm_chip)
+		pr_info("No TPM chip found, activating TPM-bypass!\n");
+

From: Yeoreum Yun <[email protected]>

This reverts commit 746d9e9f62a6e8ba0eba2b83fc61cfe7fa8797ce.

Now that IMA will retry in the late_initcall_sync level if the TPM is not available at first, this change is no longer required.

From: Yeoreum Yun <[email protected]>

This reverts commit 0e0546eabcd6c19765a8dbf5b5db3723e7b0ea75, which was added to address ordering issues with the IMA LSM initialisation where the TPM would not be fully ready by the time IMA wanted it. This has been resolved within IMA by retrying setup during late_initcall_sync if the TPM is not available at first.

From: Yeoreum Yun <[email protected]>

This reverts commit 0e0546eabcd6c19765a8dbf5b5db3723e7b0ea75, which was added to address ordering issues with the IMA LSM initialisation where the TPM would not be fully ready by the time IMA wanted it. This has been resolved within IMA by retrying setup during late_initcall_sync if the TPM is not available at first.

Signed-off-by Yeoreum Yun <[email protected]>

Signed-off-by Jonathan McDowell <[email protected]>

---
 drivers/firmware/arm_ffa/driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/firmware/arm_ffa/driver.c +1 -1

index f2f94d4d533e..01547c5c0e38 100644
@@ -2106,7 +2106,7 @@ static int __init ffa_init(void)
 	kfree(drv_info);
 	return ret;
 }
-rootfs_initcall(ffa_init);
+module_init(ffa_init);
 
 static void __exit ffa_exit(void)
 {

Signature · 1 line

2.53.0

From: Yeoreum Yun <[email protected]>

This reverts commit 0e0546eabcd6c19765a8dbf5b5db3723e7b0ea75, which was added to address ordering issues with the IMA LSM initialisation where the TPM would not be fully ready by the time IMA wanted it. This has been resolved within IMA by retrying setup during late_initcall_sync if the TPM is not available at first.

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/[email protected]/
---
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(+)

security/integrity/ima/ima.h +1 -0

index 01aae19ed365..9a1117112fb2 100644
@@ -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,

security/integrity/ima/ima_init.c +6 -0

index 5f335834a9bb..edd063b99685 100644
@@ -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;

security/integrity/ima/ima_main.c +2 -0

index 42099bfe7e43..23e669be54fc 100644
@@ -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

security/integrity/ima/ima_main.c +7 -1

+		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

With above change I confirmed there is no meaurement log between boot_aggregate and boot_aggregate_late except "kernel_version" But this is ignorable since this UTS measurement is done in "ima_init_core() (old: ima_init())" and it is part of ima initialisation.

1. ima_policy=tcb

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
  10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox
  10 17ec669c65c401e5e85875cf2962eb7d8c47595f ima-ng sha256:dc6b013e9768d9b13bcd6678470448090138ca831f4771a43ce3988d8e54ffce /lib/ld-linux-aarch64.so.1
  10 58679a66ac1de17f02595625a8fbeafa259a4c81 ima-ng sha256:494f62bcfb2fcf1b427d5092fafa62c8df39a83b4a64402620b28846724f237f /usr/lib/libtirpc.so.3.0.0
  10 42f74ee200434576e33be153830b3d55bbe6d2bf ima-ng sha256:a18856b4f6927bc2b8dd4608c0768b8f98544a161b85bf4a64419131243ad300 /lib/libresolv.so.2
  10 626b4f7bd4f123d18d3a3d8719ed0ae19ee5f331 ima-ng sha256:b8d442de5d31c3f9d1bbb98785f04d4a23dc53442b286d85d4b355927cbe9af4 /lib/libc.so.6
  10 655a200869696207646377a58cab417fd35b09d2 ima-ng sha256:ad46146b6dd32b47213e5327f1bb2f962ef838a4b707ef7445fa2dbc9019b44f /etc/inittab
  10 81353202685e022fcd0069a3b2fc4eaa6b1db537 ima-ng sha256:74d698fe0a6862050af29083aa591c960ec1f67be960047e96bb6be5fc2bc0c0 /bin/mount
  10 ae64184ee607ef8f3aa08ab52cb548318534fd4b ima-ng sha256:27846b57e8234c6a9611b00351f581a54ad6f9a1920b9aa18ceb0ae28e4f7564 /lib/libmount.so.1.1.0
  10 5ea01f34e7705d1bdb936fd576e2aeb5fd78dab9 ima-ng sha256:3d2a414ec0355fcf0910224fb4a3c53e13d98731a35241edfdf4fb911ed9b210 /lib/libblkid.so.1.1.0
  10 22c48b4853594a08a73ad4ae6dbe6f2c2bebc6c5 ima-ng sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 /run/utmp
  10 3024ea5021f8a5d9fb4bd519d599bdca43b7fb93 ima-ng sha256:71ea9ffe2b30e5a9bdceff78785cf281cc41544474db8dc4605a06a597ce1edc /etc/fstab
  10 2e7530a0f56420991ac7611734cea4774b92b9ef ima-ng sha256:df4697d699442cfe73db7cc8b4c1b37e8a31e75e01f66a0d70134ac812fa683b /bin/mkdir
  10 3ad117a863aa1ed7b7c09e1d106f84abf7d2ae96 ima-ng sha256:c19a710989b43222431b02399273dba409fe10ca8eefff88eaa936fa695f8324 /bin/ln
  10 4141c82cb516ac3c846e0b08abcd6abeee7efa1a ima-ng sha256:b75d7f28772f71715a941c77e07e3922815391dd9cc5718ad21f2231c2da09bb /etc/hostname
  10 dfcedd3c7dc3ed42e09219804504489ab264e2e3 ima-ng sha256:dc1615df9f2012b20b81ffad8e07e16293039ba7fd897854ca3646d6cfea0c0f /etc/init.d/rcS
  ...

2. ima_policy=critical_data

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late

Therefore, init_ima() could move into late_initcall_sync like v1 did:
- https://lore.kernel.org/all/[email protected]/

Quoted 34 lines · Yeoreum Yun

With above change I confirmed there is no meaurement log between boot_aggregate and boot_aggregate_late except "kernel_version" But this is ignorable since this UTS measurement is done in "ima_init_core() (old: ima_init())" and it is part of ima initialisation.

1. ima_policy=tcb

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
  10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox
  10 17ec669c65c401e5e85875cf2962eb7d8c47595f ima-ng sha256:dc6b013e9768d9b13bcd6678470448090138ca831f4771a43ce3988d8e54ffce /lib/ld-linux-aarch64.so.1
  10 58679a66ac1de17f02595625a8fbeafa259a4c81 ima-ng sha256:494f62bcfb2fcf1b427d5092fafa62c8df39a83b4a64402620b28846724f237f /usr/lib/libtirpc.so.3.0.0
  10 42f74ee200434576e33be153830b3d55bbe6d2bf ima-ng sha256:a18856b4f6927bc2b8dd4608c0768b8f98544a161b85bf4a64419131243ad300 /lib/libresolv.so.2
  10 626b4f7bd4f123d18d3a3d8719ed0ae19ee5f331 ima-ng sha256:b8d442de5d31c3f9d1bbb98785f04d4a23dc53442b286d85d4b355927cbe9af4 /lib/libc.so.6
  10 655a200869696207646377a58cab417fd35b09d2 ima-ng sha256:ad46146b6dd32b47213e5327f1bb2f962ef838a4b707ef7445fa2dbc9019b44f /etc/inittab
  10 81353202685e022fcd0069a3b2fc4eaa6b1db537 ima-ng sha256:74d698fe0a6862050af29083aa591c960ec1f67be960047e96bb6be5fc2bc0c0 /bin/mount
  10 ae64184ee607ef8f3aa08ab52cb548318534fd4b ima-ng sha256:27846b57e8234c6a9611b00351f581a54ad6f9a1920b9aa18ceb0ae28e4f7564 /lib/libmount.so.1.1.0
  10 5ea01f34e7705d1bdb936fd576e2aeb5fd78dab9 ima-ng sha256:3d2a414ec0355fcf0910224fb4a3c53e13d98731a35241edfdf4fb911ed9b210 /lib/libblkid.so.1.1.0
  10 22c48b4853594a08a73ad4ae6dbe6f2c2bebc6c5 ima-ng sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 /run/utmp
  10 3024ea5021f8a5d9fb4bd519d599bdca43b7fb93 ima-ng sha256:71ea9ffe2b30e5a9bdceff78785cf281cc41544474db8dc4605a06a597ce1edc /etc/fstab
  10 2e7530a0f56420991ac7611734cea4774b92b9ef ima-ng sha256:df4697d699442cfe73db7cc8b4c1b37e8a31e75e01f66a0d70134ac812fa683b /bin/mkdir
  10 3ad117a863aa1ed7b7c09e1d106f84abf7d2ae96 ima-ng sha256:c19a710989b43222431b02399273dba409fe10ca8eefff88eaa936fa695f8324 /bin/ln
  10 4141c82cb516ac3c846e0b08abcd6abeee7efa1a ima-ng sha256:b75d7f28772f71715a941c77e07e3922815391dd9cc5718ad21f2231c2da09bb /etc/hostname
  10 dfcedd3c7dc3ed42e09219804504489ab264e2e3 ima-ng sha256:dc1615df9f2012b20b81ffad8e07e16293039ba7fd897854ca3646d6cfea0c0f /etc/init.d/rcS
  ...

2. ima_policy=critical_data

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late

Quoted 2 lines

Therefore, init_ima() could move into late_initcall_sync like v1 did:
- https://lore.kernel.org/all/[email protected]/

Thanks, Yeoreum. It's a bit premature to claim it's "safe" to move the initcall. Hopefully others will respond.

Quoted 38 lines · Mimi Zohar

Quoted 36 lines · Yeoreum Yun

With above change I confirmed there is no meaurement log between boot_aggregate and boot_aggregate_late except "kernel_version" But this is ignorable since this UTS measurement is done in "ima_init_core() (old: ima_init())" and it is part of ima initialisation.

1. ima_policy=tcb

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
  10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox
  10 17ec669c65c401e5e85875cf2962eb7d8c47595f ima-ng sha256:dc6b013e9768d9b13bcd6678470448090138ca831f4771a43ce3988d8e54ffce /lib/ld-linux-aarch64.so.1
  10 58679a66ac1de17f02595625a8fbeafa259a4c81 ima-ng sha256:494f62bcfb2fcf1b427d5092fafa62c8df39a83b4a64402620b28846724f237f /usr/lib/libtirpc.so.3.0.0
  10 42f74ee200434576e33be153830b3d55bbe6d2bf ima-ng sha256:a18856b4f6927bc2b8dd4608c0768b8f98544a161b85bf4a64419131243ad300 /lib/libresolv.so.2
  10 626b4f7bd4f123d18d3a3d8719ed0ae19ee5f331 ima-ng sha256:b8d442de5d31c3f9d1bbb98785f04d4a23dc53442b286d85d4b355927cbe9af4 /lib/libc.so.6
  10 655a200869696207646377a58cab417fd35b09d2 ima-ng sha256:ad46146b6dd32b47213e5327f1bb2f962ef838a4b707ef7445fa2dbc9019b44f /etc/inittab
  10 81353202685e022fcd0069a3b2fc4eaa6b1db537 ima-ng sha256:74d698fe0a6862050af29083aa591c960ec1f67be960047e96bb6be5fc2bc0c0 /bin/mount
  10 ae64184ee607ef8f3aa08ab52cb548318534fd4b ima-ng sha256:27846b57e8234c6a9611b00351f581a54ad6f9a1920b9aa18ceb0ae28e4f7564 /lib/libmount.so.1.1.0
  10 5ea01f34e7705d1bdb936fd576e2aeb5fd78dab9 ima-ng sha256:3d2a414ec0355fcf0910224fb4a3c53e13d98731a35241edfdf4fb911ed9b210 /lib/libblkid.so.1.1.0
  10 22c48b4853594a08a73ad4ae6dbe6f2c2bebc6c5 ima-ng sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 /run/utmp
  10 3024ea5021f8a5d9fb4bd519d599bdca43b7fb93 ima-ng sha256:71ea9ffe2b30e5a9bdceff78785cf281cc41544474db8dc4605a06a597ce1edc /etc/fstab
  10 2e7530a0f56420991ac7611734cea4774b92b9ef ima-ng sha256:df4697d699442cfe73db7cc8b4c1b37e8a31e75e01f66a0d70134ac812fa683b /bin/mkdir
  10 3ad117a863aa1ed7b7c09e1d106f84abf7d2ae96 ima-ng sha256:c19a710989b43222431b02399273dba409fe10ca8eefff88eaa936fa695f8324 /bin/ln
  10 4141c82cb516ac3c846e0b08abcd6abeee7efa1a ima-ng sha256:b75d7f28772f71715a941c77e07e3922815391dd9cc5718ad21f2231c2da09bb /etc/hostname
  10 dfcedd3c7dc3ed42e09219804504489ab264e2e3 ima-ng sha256:dc1615df9f2012b20b81ffad8e07e16293039ba7fd897854ca3646d6cfea0c0f /etc/init.d/rcS
  ...

2. ima_policy=critical_data

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late

Therefore, init_ima() could move into late_initcall_sync like v1 did:
- https://lore.kernel.org/all/[email protected]/

Quoted 2 lines

Thanks, Yeoreum. It's a bit premature to claim it's "safe" to move the initcall. Hopefully others will respond.

Is it not possible to look at the code and determine if it is safe or not? Or is the initialization of TPM devices at boot done in a random order with respect to the initcall levels?

Quoted 39 lines · Paul Moore

Quoted 38 lines · Mimi Zohar

Quoted 36 lines · Yeoreum Yun

With above change I confirmed there is no meaurement log between boot_aggregate and boot_aggregate_late except "kernel_version" But this is ignorable since this UTS measurement is done in "ima_init_core() (old: ima_init())" and it is part of ima initialisation.

1. ima_policy=tcb

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
  10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox
  10 17ec669c65c401e5e85875cf2962eb7d8c47595f ima-ng sha256:dc6b013e9768d9b13bcd6678470448090138ca831f4771a43ce3988d8e54ffce /lib/ld-linux-aarch64.so.1
  10 58679a66ac1de17f02595625a8fbeafa259a4c81 ima-ng sha256:494f62bcfb2fcf1b427d5092fafa62c8df39a83b4a64402620b28846724f237f /usr/lib/libtirpc.so.3.0.0
  10 42f74ee200434576e33be153830b3d55bbe6d2bf ima-ng sha256:a18856b4f6927bc2b8dd4608c0768b8f98544a161b85bf4a64419131243ad300 /lib/libresolv.so.2
  10 626b4f7bd4f123d18d3a3d8719ed0ae19ee5f331 ima-ng sha256:b8d442de5d31c3f9d1bbb98785f04d4a23dc53442b286d85d4b355927cbe9af4 /lib/libc.so.6
  10 655a200869696207646377a58cab417fd35b09d2 ima-ng sha256:ad46146b6dd32b47213e5327f1bb2f962ef838a4b707ef7445fa2dbc9019b44f /etc/inittab
  10 81353202685e022fcd0069a3b2fc4eaa6b1db537 ima-ng sha256:74d698fe0a6862050af29083aa591c960ec1f67be960047e96bb6be5fc2bc0c0 /bin/mount
  10 ae64184ee607ef8f3aa08ab52cb548318534fd4b ima-ng sha256:27846b57e8234c6a9611b00351f581a54ad6f9a1920b9aa18ceb0ae28e4f7564 /lib/libmount.so.1.1.0
  10 5ea01f34e7705d1bdb936fd576e2aeb5fd78dab9 ima-ng sha256:3d2a414ec0355fcf0910224fb4a3c53e13d98731a35241edfdf4fb911ed9b210 /lib/libblkid.so.1.1.0
  10 22c48b4853594a08a73ad4ae6dbe6f2c2bebc6c5 ima-ng sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 /run/utmp
  10 3024ea5021f8a5d9fb4bd519d599bdca43b7fb93 ima-ng sha256:71ea9ffe2b30e5a9bdceff78785cf281cc41544474db8dc4605a06a597ce1edc /etc/fstab
  10 2e7530a0f56420991ac7611734cea4774b92b9ef ima-ng sha256:df4697d699442cfe73db7cc8b4c1b37e8a31e75e01f66a0d70134ac812fa683b /bin/mkdir
  10 3ad117a863aa1ed7b7c09e1d106f84abf7d2ae96 ima-ng sha256:c19a710989b43222431b02399273dba409fe10ca8eefff88eaa936fa695f8324 /bin/ln
  10 4141c82cb516ac3c846e0b08abcd6abeee7efa1a ima-ng sha256:b75d7f28772f71715a941c77e07e3922815391dd9cc5718ad21f2231c2da09bb /etc/hostname
  10 dfcedd3c7dc3ed42e09219804504489ab264e2e3 ima-ng sha256:dc1615df9f2012b20b81ffad8e07e16293039ba7fd897854ca3646d6cfea0c0f /etc/init.d/rcS
  ...

2. ima_policy=critical_data

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late

Therefore, init_ima() could move into late_initcall_sync like v1 did:
- https://lore.kernel.org/all/[email protected]/

Quoted 6 lines

Quoted 2 lines

Thanks, Yeoreum. It's a bit premature to claim it's "safe" to move the initcall. Hopefully others will respond.

Is it not possible to look at the code and determine if it is safe or not? Or is the initialization of TPM devices at boot done in a random order with respect to the initcall levels?

The TPM is normally initialized at the device_initcall, except when other resources are not ready.

(Abbreviated) AI explanation:
If the TPM's first probe succeeds at device_initcall with no deferral, IMA finds it fine. It is only when the TPM is pushed onto the deferred list that late_initcall can execute before the retry succeeds, leaving tpm_default_chip() returning NULL.

Regardless, assuming you always want IMA to leverage a TPMs when they exist, your reply suggests that using an initcall based IMA init scheme, even a late-sync initcall, may not be sufficient because deferred TPM initialization could happen later, yes?

Quoted 4 lines · Paul Moore

Regardless, assuming you always want IMA to leverage a TPMs when they exist, your reply suggests that using an initcall based IMA init scheme, even a late-sync initcall, may not be sufficient because deferred TPM initialization could happen later, yes?

Well yeah. The TPM could be configured as a module, but that scenario is not of interest. That's way too late. The case being addressed in this patch set is when the TPM driver tries to initialize at device_initcall, returns EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since ordering within an initcall is not supported, this patch attempts to initialize IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.

Quoted 6 lines · Mimi Zohar

Quoted 4 lines · Paul Moore

Regardless, assuming you always want IMA to leverage a TPMs when they exist, your reply suggests that using an initcall based IMA init scheme, even a late-sync initcall, may not be sufficient because deferred TPM initialization could happen later, yes?

Quoted 6 lines

Well yeah. The TPM could be configured as a module, but that scenario is not of interest. That's way too late. The case being addressed in this patch set is when the TPM driver tries to initialize at device_initcall, returns EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since ordering within an initcall is not supported, this patch attempts to initialize IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.

Okay, so from a TPM initialization perspective you are satisfied with a late-sync IMA initialization, yes?

Quoted 14 lines · Paul Moore

Quoted 12 lines · Mimi Zohar

Quoted 4 lines · Paul Moore

Regardless, assuming you always want IMA to leverage a TPMs when they exist, your reply suggests that using an initcall based IMA init scheme, even a late-sync initcall, may not be sufficient because deferred TPM initialization could happen later, yes?

Well yeah. The TPM could be configured as a module, but that scenario is not of interest. That's way too late. The case being addressed in this patch set is when the TPM driver tries to initialize at device_initcall, returns EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since ordering within an initcall is not supported, this patch attempts to initialize IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.

Quoted 2 lines

Okay, so from a TPM initialization perspective you are satisfied with a late-sync IMA initialization, yes?

No. On some architectures moving IMA initialization from the late_initcall to late_initcall_sync does not miss any measurement records. However, as previously mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement records[1]. So no, only if the TPM is not initialized by late_initcall, should IMA retry at late_initcall_sync.

Quoted 15 lines · Mimi Zohar

Quoted 14 lines · Paul Moore

Quoted 12 lines · Mimi Zohar

Quoted 4 lines · Paul Moore

Regardless, assuming you always want IMA to leverage a TPMs when they exist, your reply suggests that using an initcall based IMA init scheme, even a late-sync initcall, may not be sufficient because deferred TPM initialization could happen later, yes?

Well yeah. The TPM could be configured as a module, but that scenario is not of interest. That's way too late. The case being addressed in this patch set is when the TPM driver tries to initialize at device_initcall, returns EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since ordering within an initcall is not supported, this patch attempts to initialize IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.

Quoted 8 lines

Quoted 2 lines

Okay, so from a TPM initialization perspective you are satisfied with a late-sync IMA initialization, yes?

No. On some architectures moving IMA initialization from the late_initcall to late_initcall_sync does not miss any measurement records. However, as previously mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement records[1]. So no, only if the TPM is not initialized by late_initcall, should IMA retry at late_initcall_sync.

What do you do in the PowerVM LPAR when the TPM is not avaiable at late initcall and you have to defer IMA initialization until late-sync?

Quoted 25 lines · Paul Moore

Quoted 23 lines · Mimi Zohar

Quoted 14 lines · Paul Moore

Quoted 6 lines · Mimi Zohar

Quoted 4 lines · Paul Moore

Regardless, assuming you always want IMA to leverage a TPMs when they exist, your reply suggests that using an initcall based IMA init scheme, even a late-sync initcall, may not be sufficient because deferred TPM initialization could happen later, yes?

Quoted 6 lines

Well yeah. The TPM could be configured as a module, but that scenario is not of interest. That's way too late. The case being addressed in this patch set is when the TPM driver tries to initialize at device_initcall, returns EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since ordering within an initcall is not supported, this patch attempts to initialize IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.

Quoted 2 lines

Okay, so from a TPM initialization perspective you are satisfied with a late-sync IMA initialization, yes?

No. On some architectures moving IMA initialization from the late_initcall to late_initcall_sync does not miss any measurement records. However, as previously mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement records[1]. So no, only if the TPM is not initialized by late_initcall, should IMA retry at late_initcall_sync.

Quoted 3 lines

What do you do in the PowerVM LPAR when the TPM is not avaiable at late initcall and you have to defer IMA initialization until late-sync?

Your question is hypothetical ...

... as the TPM isn't deferred, so IMA doesn't go into
TPM-bypass mode. Testing on a PowerVM LPAR demonstrated that it skips ~30 measurement list records. So moving the initcall to late_initcall_sync would cause a regression.

Quoted 29 lines · Mimi Zohar

Quoted 28 lines · Paul Moore

Quoted 26 lines · Mimi Zohar

Quoted 16 lines · Paul Moore

Quoted 6 lines · Mimi Zohar

Quoted 4 lines · Paul Moore

Regardless, assuming you always want IMA to leverage a TPMs when they exist, your reply suggests that using an initcall based IMA init scheme, even a late-sync initcall, may not be sufficient because deferred TPM initialization could happen later, yes?

Quoted 8 lines

Well yeah. The TPM could be configured as a module, but that scenario is not of
interest. That's way too late. The case being addressed in this patch set is when the TPM driver tries to initialize at device_initcall, returns EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since ordering within an initcall is not supported, this patch attempts to initialize IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.

Quoted 2 lines

Okay, so from a TPM initialization perspective you are satisfied with a late-sync IMA initialization, yes?

No. On some architectures moving IMA initialization from the late_initcall to late_initcall_sync does not miss any measurement records. However, as previously
mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement records[1]. So no, only if the TPM is not initialized by late_initcall, should IMA retry at late_initcall_sync.

Quoted 5 lines

Quoted 3 lines

What do you do in the PowerVM LPAR when the TPM is not avaiable at late initcall and you have to defer IMA initialization until late-sync?

Your question is hypothetical ...

<heavy eye roll>

Quoted 4 lines

... as the TPM isn't deferred, so IMA doesn't go into
TPM-bypass mode. Testing on a PowerVM LPAR demonstrated that it skips ~30 measurement list records. So moving the initcall to late_initcall_sync would cause a regression.

Let me rephrase to make the question clear - how do you plan to handle a system where you lose measurements by waiting until late-sync, but the TPM is not available at the late initcall.

Quoted 38 lines · Paul Moore

Quoted 29 lines · Mimi Zohar

Quoted 28 lines · Paul Moore

Quoted 26 lines · Mimi Zohar

Quoted 16 lines · Paul Moore

Quoted 6 lines · Mimi Zohar

Quoted 4 lines · Paul Moore

Regardless, assuming you always want IMA to leverage a TPMs when they exist, your reply suggests that using an initcall based IMA init scheme, even a late-sync initcall, may not be sufficient because deferred TPM initialization could happen later, yes?

Quoted 8 lines

Well yeah. The TPM could be configured as a module, but that scenario is not of
interest. That's way too late. The case being addressed in this patch set is when the TPM driver tries to initialize at device_initcall, returns EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since ordering within an initcall is not supported, this patch attempts to initialize IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.

Quoted 2 lines

Okay, so from a TPM initialization perspective you are satisfied with a late-sync IMA initialization, yes?

No. On some architectures moving IMA initialization from the late_initcall to late_initcall_sync does not miss any measurement records. However, as previously
mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement records[1]. So no, only if the TPM is not initialized by late_initcall, should IMA retry at late_initcall_sync.

Quoted 5 lines

Quoted 3 lines

What do you do in the PowerVM LPAR when the TPM is not avaiable at late initcall and you have to defer IMA initialization until late-sync?

Your question is hypothetical ...

<heavy eye roll>

Quoted 8 lines

Quoted 4 lines

... as the TPM isn't deferred, so IMA doesn't go into
TPM-bypass mode. Testing on a PowerVM LPAR demonstrated that it skips ~30 measurement list records. So moving the initcall to late_initcall_sync would cause a regression.

Let me rephrase to make the question clear - how do you plan to handle a system where you lose measurements by waiting until late-sync, but the TPM is not available at the late initcall.

There have been suggestions to queue the IMA measurements, but that goes against the "measure before use" principle. The solution is not to defer IMA initialization for all systems, but to differentiate the boot_aggregate record (boot_aggregate vs. boot_aggregate_late) based on when the TPM becomes available relative to IMA's initcall. IMA's job is simply to collect and provide the measurement list. Based on the attestation service policy, the attestation service will decide whether a measurement list containing boot_aggregate_late is acceptable.

Quoted 48 lines · Mimi Zohar

Quoted 38 lines · Paul Moore

Quoted 29 lines · Mimi Zohar

Quoted 28 lines · Paul Moore

Quoted 26 lines · Mimi Zohar

Quoted 16 lines · Paul Moore

Quoted 6 lines · Mimi Zohar

Quoted 4 lines · Paul Moore

Regardless, assuming you always want IMA to leverage a TPMs when they exist, your reply suggests that using an initcall based IMA init scheme, even a late-sync initcall, may not be sufficient because deferred TPM initialization could happen later, yes?

Quoted 8 lines

Well yeah. The TPM could be configured as a module, but that scenario is not of
interest. That's way too late. The case being addressed in this patch set is when the TPM driver tries to initialize at device_initcall, returns EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since ordering within an initcall is not supported, this patch attempts to initialize IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.

Quoted 2 lines

Okay, so from a TPM initialization perspective you are satisfied with a late-sync IMA initialization, yes?

No. On some architectures moving IMA initialization from the late_initcall to late_initcall_sync does not miss any measurement records. However, as previously
mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement records[1]. So no, only if the TPM is not initialized by late_initcall, should IMA retry at late_initcall_sync.

Quoted 5 lines

Quoted 3 lines

What do you do in the PowerVM LPAR when the TPM is not avaiable at late initcall and you have to defer IMA initialization until late-sync?

Your question is hypothetical ...

<heavy eye roll>

Quoted 8 lines

Quoted 4 lines

... as the TPM isn't deferred, so IMA doesn't go into
TPM-bypass mode. Testing on a PowerVM LPAR demonstrated that it skips ~30 measurement list records. So moving the initcall to late_initcall_sync would cause a regression.

Let me rephrase to make the question clear - how do you plan to handle a system where you lose measurements by waiting until late-sync, but the TPM is not available at the late initcall.

Quoted 8 lines

There have been suggestions to queue the IMA measurements, but that goes against the "measure before use" principle. The solution is not to defer IMA initialization for all systems, but to differentiate the boot_aggregate record (boot_aggregate vs. boot_aggregate_late) based on when the TPM becomes available relative to IMA's initcall. IMA's job is simply to collect and provide the measurement list. Based on the attestation service policy, the attestation service will decide whether a measurement list containing boot_aggregate_late is acceptable.

Agreed on no violation of the measure and load principle.

But also the two boot_aggregate solution does not work. If there are measurements before boot_aggregate_late, they can corrupt the system without noticing, and the corrupted system would emit the boot_aggregate measurement (non-late) to pass verification.

Quoted 11 lines · Yeoreum Yun

With above change I confirmed there is no meaurement log between boot_aggregate and boot_aggregate_late except "kernel_version" But this is ignorable since this UTS measurement is done in "ima_init_core() (old: ima_init())" and it is part of ima initialisation.

1. ima_policy=tcb

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
  10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox

Quoted 8 lines

2. ima_policy=critical_data

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late

Quoted 2 lines

Therefore, init_ima() could move into late_initcall_sync like v1 did:
- https://lore.kernel.org/all/[email protected]/

Thanks, Yeoreum. It's a bit premature to claim it's "safe" to move the initcall. Hopefully others will respond.

Mimi

Quoted 13 lines · Mimi Zohar

Quoted 11 lines · Yeoreum Yun

With above change I confirmed there is no meaurement log between boot_aggregate and boot_aggregate_late except "kernel_version" But this is ignorable since this UTS measurement is done in "ima_init_core() (old: ima_init())" and it is part of ima initialisation.

1. ima_policy=tcb

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
  10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox

snip

Quoted 8 lines

Quoted 8 lines

2. ima_policy=critical_data

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late

Quoted 7 lines

Quoted 2 lines

Therefore, init_ima() could move into late_initcall_sync like v1 did:
- https://lore.kernel.org/all/[email protected]/

Thanks, Yeoreum. It's a bit premature to claim it's "safe" to move the initcall. Hopefully others will respond.

Mimi

I have also run with this patch on a number of bare metal and virtual machines, running everything from default Fedora 44 to a version with everything turned on (uefi secure boot, UKI with sdboot stub measurements, IMA measurement and appraisal enabled,
all systemd measurements on, and systemd using the TPM for root partition decryption.)
I too see only the kernel_version event between the normal and late calls, if ima_policy=critical_data.

Quoted 31 lines · David Safford

Quoted 13 lines · Mimi Zohar

Quoted 11 lines · Yeoreum Yun

With above change I confirmed there is no meaurement log between boot_aggregate and boot_aggregate_late except "kernel_version" But this is ignorable since this UTS measurement is done in "ima_init_core() (old: ima_init())" and it is part of ima initialisation.

1. ima_policy=tcb

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
  10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox

snip

Quoted 8 lines

Quoted 8 lines

2. ima_policy=critical_data

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late

Quoted 7 lines

Quoted 2 lines

Therefore, init_ima() could move into late_initcall_sync like v1 did:
- https://lore.kernel.org/all/[email protected]/

Thanks, Yeoreum. It's a bit premature to claim it's "safe" to move the initcall. Hopefully others will respond.

Mimi

Quoted 8 lines

I have also run with this patch on a number of bare metal and virtual machines, running everything from default Fedora 44 to a version with everything turned on (uefi secure boot, UKI with sdboot stub measurements, IMA measurement and appraisal enabled,
all systemd measurements on, and systemd using the TPM for root partition decryption.)
I too see only the kernel_version event between the normal and late calls, if ima_policy=critical_data.

Thanks, Dave! Were all the systems you tested x86_64? The next step would be to test on different arch's (e.g. Z, Power).

Quoted 41 lines · David Safford

Quoted 31 lines · Mimi Zohar

Quoted 13 lines · Yeoreum Yun

Quoted 11 lines

With above change I confirmed there is no meaurement log between boot_aggregate and boot_aggregate_late except "kernel_version" But this is ignorable since this UTS measurement is done in "ima_init_core() (old: ima_init())" and it is part of ima initialisation.

1. ima_policy=tcb

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
  10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox

snip

Quoted 8 lines

Quoted 8 lines

2. ima_policy=critical_data

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late

Quoted 7 lines

Quoted 2 lines

Therefore, init_ima() could move into late_initcall_sync like v1 did:
- https://lore.kernel.org/all/[email protected]/

Thanks, Yeoreum. It's a bit premature to claim it's "safe" to move the initcall. Hopefully others will respond.

Mimi

Quoted 8 lines

I have also run with this patch on a number of bare metal and virtual machines, running everything from default Fedora 44 to a version with everything turned on (uefi secure boot, UKI with sdboot stub measurements, IMA measurement and appraisal enabled,
all systemd measurements on, and systemd using the TPM for root partition decryption.)
I too see only the kernel_version event between the normal and late calls, if ima_policy=critical_data.

Quoted 2 lines

Thanks, Dave! Were all the systems you tested x86_64? The next step would be to test on different arch's (e.g. Z, Power).

On both Z and PowerVM, there are ~30 measurements between boot_aggregate and boot_aggregate_late. For example, on PowerVM:

# grep -n boot_aggregate
/sys/kernel/security/integrity/ima/ascii_runtime_measurements

1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate
31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate_late

It would be interesting to the results from a Raspberry Pi 5 as well, with/without a TPM.

Quoted 58 lines · Mimi Zohar

Quoted 41 lines · David Safford

Quoted 31 lines · Mimi Zohar

Quoted 13 lines · Yeoreum Yun

Quoted 11 lines

With above change I confirmed there is no meaurement log between boot_aggregate and boot_aggregate_late except "kernel_version" But this is ignorable since this UTS measurement is done in "ima_init_core() (old: ima_init())" and it is part of ima initialisation.

1. ima_policy=tcb

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
  10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox

snip

Quoted 8 lines

Quoted 8 lines

2. ima_policy=critical_data

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late

Quoted 7 lines

Quoted 2 lines

Therefore, init_ima() could move into late_initcall_sync like v1 did:
- https://lore.kernel.org/all/[email protected]/

Thanks, Yeoreum. It's a bit premature to claim it's "safe" to move the initcall. Hopefully others will respond.

Mimi

Quoted 8 lines

I have also run with this patch on a number of bare metal and virtual machines, running everything from default Fedora 44 to a version with everything turned on (uefi secure boot, UKI with sdboot stub measurements, IMA measurement and appraisal enabled,
all systemd measurements on, and systemd using the TPM for root partition decryption.)
I too see only the kernel_version event between the normal and late calls, if ima_policy=critical_data.

Quoted 2 lines

Thanks, Dave! Were all the systems you tested x86_64? The next step would be to test on different arch's (e.g. Z, Power).

On both Z and PowerVM, there are ~30 measurements between boot_aggregate and boot_aggregate_late. For example, on PowerVM:

# grep -n boot_aggregate
/sys/kernel/security/integrity/ima/ascii_runtime_measurements

1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate
31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate_late

Quoted 2 lines

It would be interesting to the results from a Raspberry Pi 5 as well, with/without a TPM.

Honestly, I find this result hard to accept.

This effectively means that there is code invoking IMA measurement during late_initcall(). It also implies that if, in the future, a late_initcall is added that performs an IMA measurement before IMA initialization has occurred accoding to order by linker, that measurement could be missed.

Could you please check how the index (1, 31) was added to either ima_template_entry or ima_queue_entry to produce this result?

Signature · 3 lines

-- 
Sincerely,
Yeoreum Yun

Hi Mimi,

Quoted 58 lines · Mimi Zohar

Quoted 41 lines · David Safford

Quoted 31 lines · Mimi Zohar

Quoted 13 lines · Yeoreum Yun

Quoted 11 lines

With above change I confirmed there is no meaurement log between boot_aggregate and boot_aggregate_late except "kernel_version" But this is ignorable since this UTS measurement is done in "ima_init_core() (old: ima_init())" and it is part of ima initialisation.

1. ima_policy=tcb

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
  10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox

snip

Quoted 8 lines

Quoted 8 lines

2. ima_policy=critical_data

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late

Quoted 7 lines

Quoted 2 lines

Therefore, init_ima() could move into late_initcall_sync like v1 did:
- https://lore.kernel.org/all/[email protected]/

Thanks, Yeoreum. It's a bit premature to claim it's "safe" to move the initcall. Hopefully others will respond.

Mimi

Quoted 8 lines

I have also run with this patch on a number of bare metal and virtual machines, running everything from default Fedora 44 to a version with everything turned on (uefi secure boot, UKI with sdboot stub measurements, IMA measurement and appraisal enabled,
all systemd measurements on, and systemd using the TPM for root partition decryption.)
I too see only the kernel_version event between the normal and late calls, if ima_policy=critical_data.

Quoted 2 lines

Thanks, Dave! Were all the systems you tested x86_64? The next step would be to test on different arch's (e.g. Z, Power).

On both Z and PowerVM, there are ~30 measurements between boot_aggregate and boot_aggregate_late. For example, on PowerVM:

# grep -n boot_aggregate
/sys/kernel/security/integrity/ima/ascii_runtime_measurements

1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate
31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate_late

Quoted 2 lines

It would be interesting to the results from a Raspberry Pi 5 as well, with/without a TPM.

Honestly, I find this result hard to accept.

This effectively means that there is code invoking IMA measurement during late_initcall(). It also implies that if, in the future, a late_initcall is added that performs an IMA measurement before IMA initialization has occurred accoding to order by linker, that measurement could be missed.

Could you please check how the index (1, 31) was added to either ima_template_entry or ima_queue_entry to produce this result?

Quoted 63 lines

Hi Mimi,

Quoted 58 lines · Mimi Zohar

Quoted 41 lines · David Safford

Quoted 31 lines · Mimi Zohar

Quoted 13 lines · Yeoreum Yun

Quoted 11 lines

With above change I confirmed there is no meaurement log between boot_aggregate and boot_aggregate_late except "kernel_version" But this is ignorable since this UTS measurement is done in "ima_init_core() (old: ima_init())" and it is part of ima initialisation.

1. ima_policy=tcb

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
  10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox

snip

Quoted 8 lines

Quoted 8 lines

2. ima_policy=critical_data

  # cat /sys/kernel/security/ima/ascii_runtime_measurements
  10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
  10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
  10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late

Quoted 7 lines

Quoted 2 lines

Therefore, init_ima() could move into late_initcall_sync like v1 did:
- https://lore.kernel.org/all/[email protected]/

Thanks, Yeoreum. It's a bit premature to claim it's "safe" to move the initcall. Hopefully others will respond.

Mimi

Quoted 8 lines

I have also run with this patch on a number of bare metal and virtual machines, running everything from default Fedora 44 to a version with everything turned on (uefi secure boot, UKI with sdboot stub measurements, IMA measurement and appraisal enabled,
all systemd measurements on, and systemd using the TPM for root partition decryption.)
I too see only the kernel_version event between the normal and late calls, if ima_policy=critical_data.

Quoted 2 lines

Thanks, Dave! Were all the systems you tested x86_64? The next step would be to test on different arch's (e.g. Z, Power).

On both Z and PowerVM, there are ~30 measurements between boot_aggregate and boot_aggregate_late. For example, on PowerVM:

# grep -n boot_aggregate
/sys/kernel/security/integrity/ima/ascii_runtime_measurements

1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate
31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate_late

Quoted 2 lines

It would be interesting to the results from a Raspberry Pi 5 as well, with/without a TPM.

Quoted 6 lines

Honestly, I find this result hard to accept.

This effectively means that there is code invoking IMA measurement during late_initcall(). It also implies that if, in the future, a late_initcall is added that performs an IMA measurement before IMA initialization has occurred accoding to order by linker, that measurement could be missed.

Exactly. The results are simply from booting with the builtin "tcb" and "critical_data" policies.

$ sudo grubby --args="ima_policy=\"tcb|critical_data\"" --update-kernel
/boot/vmlinuz-${SUFFIX}

Quoted 23 lines

Quoted 16 lines

Quoted 13 lines

On both Z and PowerVM, there are ~30 measurements between boot_aggregate and boot_aggregate_late. For example, on PowerVM:

# grep -n boot_aggregate
/sys/kernel/security/integrity/ima/ascii_runtime_measurements

1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate
31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate_late

Quoted 2 lines

It would be interesting to the results from a Raspberry Pi 5 as well, with/without a TPM.

Quoted 6 lines

Honestly, I find this result hard to accept.

This effectively means that there is code invoking IMA measurement during late_initcall(). It also implies that if, in the future, a late_initcall is added that performs an IMA measurement before IMA initialization has occurred accoding to order by linker, that measurement could be missed.

Quoted 5 lines

Exactly. The results are simply from booting with the builtin "tcb" and "critical_data" policies.

$ sudo grubby --args="ima_policy=\"tcb|critical_data\"" --update-kernel
/boot/vmlinuz-${SUFFIX}

Thanks. but I still wonder what meaasurements there are between boot_aggregate and boot_aggregate_late.
Might be there would be key measurements if it takes more than 5 mins before generating boot_aggregate_late but this seems rare.

If you don't mind, would you share the contents of the log between boot_aggregate and boot_aggregate_late?
since I only get a kernel_version in my environment.

And I think we can collect missing measurements before ima_init_core() into another separate list than ima_measurements in ima_add_template_entry() and we can extend them after boot_aggreagate log generation at ima_init_core() then ima initialisation could be moved to late_initcall_sync like (just for a test and share concept):

Quoted 29 lines

Quoted 23 lines

Quoted 16 lines

Quoted 13 lines

On both Z and PowerVM, there are ~30 measurements between boot_aggregate and boot_aggregate_late. For example, on PowerVM:

# grep -n boot_aggregate
/sys/kernel/security/integrity/ima/ascii_runtime_measurements

1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate
31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate_late

Quoted 2 lines

It would be interesting to the results from a Raspberry Pi 5 as well, with/without a TPM.

Quoted 6 lines

Honestly, I find this result hard to accept.

This effectively means that there is code invoking IMA measurement during late_initcall(). It also implies that if, in the future, a late_initcall is added that performs an IMA measurement before IMA initialization has occurred accoding to order by linker, that measurement could be missed.

Quoted 5 lines

Exactly. The results are simply from booting with the builtin "tcb" and "critical_data" policies.

$ sudo grubby --args="ima_policy=\"tcb|critical_data\"" --update-kernel
/boot/vmlinuz-${SUFFIX}

Quoted 8 lines

Thanks. but I still wonder what meaasurements there are between boot_aggregate and boot_aggregate_late.
Might be there would be key measurements if it takes more than 5 mins before generating boot_aggregate_late but this seems rare.

If you don't mind, would you share the contents of the log between boot_aggregate and boot_aggregate_late?
since I only get a kernel_version in my environment.

     1	10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate 
     2	10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
kernel_version 372e312e302d7263312b
     3	10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
/usr/bin/kmod 
     4	10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
/usr/lib64/ld64.so.2 
     5	10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
/etc/ld.so.cache 
     6	10 e047868f01908eb95aa180693291decab82bb6be ima-sig
sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
/usr/lib64/libzstd.so.1.5.5 
     7	10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
/usr/lib64/liblzma.so.5.6.2 
     8	10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
/usr/lib64/libz.so.1.3.1.zlib-ng 
     9	10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
/usr/lib64/libcrypto.so.3.5.1 
    10	10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
/usr/lib64/libgcc_s-14-20250617.so.1 
    11	10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
/usr/lib64/glibc-hwcaps/power10/libc.so.6 
    12	10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
/usr/lib/modprobe.d/dist-alsa.conf 
    13	10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
/usr/lib/modprobe.d/dist-blacklist.conf 
    14	10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
/etc/modprobe.d/firewalld-sysctls.conf 
    15	10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
/etc/modprobe.d/l2tp_eth-blacklist.conf 
    16	10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
/etc/modprobe.d/l2tp_ip-blacklist.conf 
    17	10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
/etc/modprobe.d/l2tp_ip6-blacklist.conf 
    18	10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
/etc/modprobe.d/l2tp_netlink-blacklist.conf 
    19	10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
/etc/modprobe.d/l2tp_ppp-blacklist.conf 
    20	10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
/usr/lib/modules/7.1.0-rc1+/modules.softdep 
    21	10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
/etc/modprobe.d/sctp-blacklist.conf 
    22	10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
/etc/modprobe.d/sctp_diag-blacklist.conf 
    23	10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
/usr/lib/modprobe.d/systemd.conf 
    24	10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
/etc/modprobe.d/tipc_diag-blacklist.conf 
    25	10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
/etc/modprobe.d/tuned.conf 
    26	10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
/usr/lib/modules/7.1.0-rc1+/modules.dep.bin 
    27	10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
/usr/lib/modules/7.1.0-rc1+/modules.alias.bin 
    28	10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
/usr/lib/modules/7.1.0-rc1+/modules.symbols.bin 
    29	10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
/usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin 
    30	10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
/usr/lib/modules/7.1.0-rc1+/modules.builtin.bin 
    31	10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate_late 
    32	10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig

sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e /usr/lib/systemd/systemd

Hi Mimi,

Quoted 133 lines · Yeoreum Yun

Quoted 29 lines

Quoted 23 lines

Quoted 16 lines

Quoted 13 lines

On both Z and PowerVM, there are ~30 measurements between boot_aggregate and boot_aggregate_late. For example, on PowerVM:

# grep -n boot_aggregate
/sys/kernel/security/integrity/ima/ascii_runtime_measurements

1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate
31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate_late

Quoted 2 lines

It would be interesting to the results from a Raspberry Pi 5 as well, with/without a TPM.

Quoted 6 lines

Honestly, I find this result hard to accept.

This effectively means that there is code invoking IMA measurement during late_initcall(). It also implies that if, in the future, a late_initcall is added that performs an IMA measurement before IMA initialization has occurred accoding to order by linker, that measurement could be missed.

Quoted 5 lines

Exactly. The results are simply from booting with the builtin "tcb" and "critical_data" policies.

$ sudo grubby --args="ima_policy=\"tcb|critical_data\"" --update-kernel
/boot/vmlinuz-${SUFFIX}

Quoted 8 lines

Thanks. but I still wonder what meaasurements there are between boot_aggregate and boot_aggregate_late.
Might be there would be key measurements if it takes more than 5 mins before generating boot_aggregate_late but this seems rare.

If you don't mind, would you share the contents of the log between boot_aggregate and boot_aggregate_late?
since I only get a kernel_version in my environment.

     1	10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate 
     2	10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
kernel_version 372e312e302d7263312b
     3	10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
/usr/bin/kmod 
     4	10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
/usr/lib64/ld64.so.2 
     5	10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
/etc/ld.so.cache 
     6	10 e047868f01908eb95aa180693291decab82bb6be ima-sig
sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
/usr/lib64/libzstd.so.1.5.5 
     7	10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
/usr/lib64/liblzma.so.5.6.2 
     8	10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
/usr/lib64/libz.so.1.3.1.zlib-ng 
     9	10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
/usr/lib64/libcrypto.so.3.5.1 
    10	10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
/usr/lib64/libgcc_s-14-20250617.so.1 
    11	10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
/usr/lib64/glibc-hwcaps/power10/libc.so.6 
    12	10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
/usr/lib/modprobe.d/dist-alsa.conf 
    13	10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
/usr/lib/modprobe.d/dist-blacklist.conf 
    14	10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
/etc/modprobe.d/firewalld-sysctls.conf 
    15	10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
/etc/modprobe.d/l2tp_eth-blacklist.conf 
    16	10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
/etc/modprobe.d/l2tp_ip-blacklist.conf 
    17	10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
/etc/modprobe.d/l2tp_ip6-blacklist.conf 
    18	10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
/etc/modprobe.d/l2tp_netlink-blacklist.conf 
    19	10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
/etc/modprobe.d/l2tp_ppp-blacklist.conf 
    20	10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
/usr/lib/modules/7.1.0-rc1+/modules.softdep 
    21	10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
/etc/modprobe.d/sctp-blacklist.conf 
    22	10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
/etc/modprobe.d/sctp_diag-blacklist.conf 
    23	10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
/usr/lib/modprobe.d/systemd.conf 
    24	10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
/etc/modprobe.d/tipc_diag-blacklist.conf 
    25	10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
/etc/modprobe.d/tuned.conf 
    26	10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
/usr/lib/modules/7.1.0-rc1+/modules.dep.bin 
    27	10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
/usr/lib/modules/7.1.0-rc1+/modules.alias.bin 
    28	10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
/usr/lib/modules/7.1.0-rc1+/modules.symbols.bin 
    29	10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
/usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin 
    30	10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
/usr/lib/modules/7.1.0-rc1+/modules.builtin.bin 
    31	10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate_late 
    32	10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig

Quoted 2 lines

sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e /usr/lib/systemd/systemd

Hmm... Theses measurements seems to happen while populating initramfs which triggers file_post_open as async (and I see the RAMFS seems not part of DONT_MEASURE in IMA).

If you don't mind, Could you check whether this measurements still happen with initramfs_async=0?

If this measurements aren't generated with above option,
there is a question whether let IMA measure initramfs which can be measured or not depending on boot option or timing (some file measurements could be lost all when do_populate_rootfs() executes concurrently while running late_initcall).

Quoted 142 lines

Hi Mimi,

Quoted 133 lines · Yeoreum Yun

Quoted 29 lines

Quoted 23 lines

Quoted 16 lines

Quoted 13 lines

On both Z and PowerVM, there are ~30 measurements between boot_aggregate and boot_aggregate_late. For example, on PowerVM:

# grep -n boot_aggregate
/sys/kernel/security/integrity/ima/ascii_runtime_measurements

1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate
31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate_late

Quoted 2 lines

It would be interesting to the results from a Raspberry Pi 5 as well, with/without a TPM.

Quoted 6 lines

Honestly, I find this result hard to accept.

This effectively means that there is code invoking IMA measurement during late_initcall(). It also implies that if, in the future, a late_initcall is added that performs an IMA measurement before IMA initialization has occurred accoding to order by linker, that measurement could be missed.

Quoted 5 lines

Exactly. The results are simply from booting with the builtin "tcb" and "critical_data" policies.

$ sudo grubby --args="ima_policy=\"tcb|critical_data\"" --update-kernel
/boot/vmlinuz-${SUFFIX}

Quoted 8 lines

Thanks. but I still wonder what meaasurements there are between boot_aggregate and boot_aggregate_late.
Might be there would be key measurements if it takes more than 5 mins before generating boot_aggregate_late but this seems rare.

If you don't mind, would you share the contents of the log between boot_aggregate and boot_aggregate_late?
since I only get a kernel_version in my environment.

     1	10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate 
     2	10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
kernel_version 372e312e302d7263312b
     3	10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
/usr/bin/kmod 
     4	10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
/usr/lib64/ld64.so.2 
     5	10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
/etc/ld.so.cache 
     6	10 e047868f01908eb95aa180693291decab82bb6be ima-sig
sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
/usr/lib64/libzstd.so.1.5.5 
     7	10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
/usr/lib64/liblzma.so.5.6.2 
     8	10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
/usr/lib64/libz.so.1.3.1.zlib-ng 
     9	10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
/usr/lib64/libcrypto.so.3.5.1 
    10	10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
/usr/lib64/libgcc_s-14-20250617.so.1 
    11	10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
/usr/lib64/glibc-hwcaps/power10/libc.so.6 
    12	10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
/usr/lib/modprobe.d/dist-alsa.conf 
    13	10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
/usr/lib/modprobe.d/dist-blacklist.conf 
    14	10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
/etc/modprobe.d/firewalld-sysctls.conf 
    15	10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
/etc/modprobe.d/l2tp_eth-blacklist.conf 
    16	10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
/etc/modprobe.d/l2tp_ip-blacklist.conf 
    17	10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
/etc/modprobe.d/l2tp_ip6-blacklist.conf 
    18	10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
/etc/modprobe.d/l2tp_netlink-blacklist.conf 
    19	10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
/etc/modprobe.d/l2tp_ppp-blacklist.conf 
    20	10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
/usr/lib/modules/7.1.0-rc1+/modules.softdep 
    21	10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
/etc/modprobe.d/sctp-blacklist.conf 
    22	10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
/etc/modprobe.d/sctp_diag-blacklist.conf 
    23	10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
/usr/lib/modprobe.d/systemd.conf 
    24	10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
/etc/modprobe.d/tipc_diag-blacklist.conf 
    25	10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
/etc/modprobe.d/tuned.conf 
    26	10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
/usr/lib/modules/7.1.0-rc1+/modules.dep.bin 
    27	10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
/usr/lib/modules/7.1.0-rc1+/modules.alias.bin 
    28	10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
/usr/lib/modules/7.1.0-rc1+/modules.symbols.bin 
    29	10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
/usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin 
    30	10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
/usr/lib/modules/7.1.0-rc1+/modules.builtin.bin 
    31	10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate_late 
    32	10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig

Quoted 2 lines

sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e /usr/lib/systemd/systemd

Hmm... Theses measurements seems to happen while populating initramfs which triggers file_post_open as async (and I see the RAMFS seems not part of DONT_MEASURE in IMA).

Quoted 8 lines

If you don't mind, Could you check whether this measurements still happen with initramfs_async=0?

If this measurements aren't generated with above option,
there is a question whether let IMA measure initramfs which can be measured or not depending on boot option or timing (some file measurements could be lost all when do_populate_rootfs() executes concurrently while running late_initcall).

There's no difference when adding the "initramfs_async=0" boot command line argument. The measurement list between boot_aggregate and boot_aggregate_late is exactly the same.

Quoted 153 lines · Yeoreum Yun

Quoted 142 lines

Hi Mimi,

Quoted 133 lines · Yeoreum Yun

Quoted 29 lines

Quoted 23 lines

Quoted 16 lines

Quoted 13 lines

On both Z and PowerVM, there are ~30 measurements between boot_aggregate and boot_aggregate_late. For example, on PowerVM:

# grep -n boot_aggregate
/sys/kernel/security/integrity/ima/ascii_runtime_measurements

1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate
31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate_late

Quoted 2 lines

It would be interesting to the results from a Raspberry Pi 5 as well, with/without a TPM.

Quoted 6 lines

Honestly, I find this result hard to accept.

This effectively means that there is code invoking IMA measurement during late_initcall(). It also implies that if, in the future, a late_initcall is added that performs an IMA measurement before IMA initialization has occurred accoding to order by linker, that measurement could be missed.

Quoted 5 lines

Exactly. The results are simply from booting with the builtin "tcb" and "critical_data" policies.

$ sudo grubby --args="ima_policy=\"tcb|critical_data\"" --update-kernel
/boot/vmlinuz-${SUFFIX}

Quoted 8 lines

Thanks. but I still wonder what meaasurements there are between boot_aggregate and boot_aggregate_late.
Might be there would be key measurements if it takes more than 5 mins before generating boot_aggregate_late but this seems rare.

If you don't mind, would you share the contents of the log between boot_aggregate and boot_aggregate_late?
since I only get a kernel_version in my environment.

     1	10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate 
     2	10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
kernel_version 372e312e302d7263312b
     3	10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
/usr/bin/kmod 
     4	10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
/usr/lib64/ld64.so.2 
     5	10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
/etc/ld.so.cache 
     6	10 e047868f01908eb95aa180693291decab82bb6be ima-sig
sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
/usr/lib64/libzstd.so.1.5.5 
     7	10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
/usr/lib64/liblzma.so.5.6.2 
     8	10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
/usr/lib64/libz.so.1.3.1.zlib-ng 
     9	10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
/usr/lib64/libcrypto.so.3.5.1 
    10	10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
/usr/lib64/libgcc_s-14-20250617.so.1 
    11	10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
/usr/lib64/glibc-hwcaps/power10/libc.so.6 
    12	10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
/usr/lib/modprobe.d/dist-alsa.conf 
    13	10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
/usr/lib/modprobe.d/dist-blacklist.conf 
    14	10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
/etc/modprobe.d/firewalld-sysctls.conf 
    15	10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
/etc/modprobe.d/l2tp_eth-blacklist.conf 
    16	10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
/etc/modprobe.d/l2tp_ip-blacklist.conf 
    17	10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
/etc/modprobe.d/l2tp_ip6-blacklist.conf 
    18	10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
/etc/modprobe.d/l2tp_netlink-blacklist.conf 
    19	10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
/etc/modprobe.d/l2tp_ppp-blacklist.conf 
    20	10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
/usr/lib/modules/7.1.0-rc1+/modules.softdep 
    21	10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
/etc/modprobe.d/sctp-blacklist.conf 
    22	10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
/etc/modprobe.d/sctp_diag-blacklist.conf 
    23	10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
/usr/lib/modprobe.d/systemd.conf 
    24	10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
/etc/modprobe.d/tipc_diag-blacklist.conf 
    25	10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
/etc/modprobe.d/tuned.conf 
    26	10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
/usr/lib/modules/7.1.0-rc1+/modules.dep.bin 
    27	10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
/usr/lib/modules/7.1.0-rc1+/modules.alias.bin 
    28	10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
/usr/lib/modules/7.1.0-rc1+/modules.symbols.bin 
    29	10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
/usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin 
    30	10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
/usr/lib/modules/7.1.0-rc1+/modules.builtin.bin 
    31	10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate_late 
    32	10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig

Quoted 2 lines

sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e /usr/lib/systemd/systemd

Hmm... Theses measurements seems to happen while populating initramfs which triggers file_post_open as async (and I see the RAMFS seems not part of DONT_MEASURE in IMA).

Quoted 8 lines

If you don't mind, Could you check whether this measurements still happen with initramfs_async=0?

If this measurements aren't generated with above option,
there is a question whether let IMA measure initramfs which can be measured or not depending on boot option or timing (some file measurements could be lost all when do_populate_rootfs() executes concurrently while running late_initcall).

Quoted 4 lines

There's no difference when adding the "initramfs_async=0" boot command line argument. The measurement list between boot_aggregate and boot_aggregate_late is exactly the same.

That's quite interesting. This means there're some file operation between late_initcall and late_initcall_sync
even before run_init_process() except initramfs population.

Since initramfs population flush all fputs() it generates and boot_aggregate_late is generated before init process is loaded, I honestly have no idea who triggers above file operations.

And it seems a little bit weird that it opens the /usr/bin/kmod and its configuration from kernel not by init_process or other user process...

Hi Mimi,

Quoted 162 lines

Quoted 153 lines · Yeoreum Yun

Quoted 142 lines

Hi Mimi,

Quoted 133 lines · Yeoreum Yun

Quoted 29 lines

Quoted 23 lines

Quoted 16 lines

Quoted 13 lines

On both Z and PowerVM, there are ~30 measurements between boot_aggregate and boot_aggregate_late. For example, on PowerVM:

# grep -n boot_aggregate
/sys/kernel/security/integrity/ima/ascii_runtime_measurements

1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate
31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate_late

Quoted 2 lines

It would be interesting to the results from a Raspberry Pi 5 as well, with/without a TPM.

Quoted 6 lines

Honestly, I find this result hard to accept.

This effectively means that there is code invoking IMA measurement during late_initcall(). It also implies that if, in the future, a late_initcall is added that performs an IMA measurement before IMA initialization has occurred accoding to order by linker, that measurement could be missed.

Quoted 5 lines

Exactly. The results are simply from booting with the builtin "tcb" and "critical_data" policies.

$ sudo grubby --args="ima_policy=\"tcb|critical_data\"" --update-kernel
/boot/vmlinuz-${SUFFIX}

Quoted 8 lines

Thanks. but I still wonder what meaasurements there are between boot_aggregate and boot_aggregate_late.
Might be there would be key measurements if it takes more than 5 mins before generating boot_aggregate_late but this seems rare.

If you don't mind, would you share the contents of the log between boot_aggregate and boot_aggregate_late?
since I only get a kernel_version in my environment.

     1	10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate 
     2	10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
kernel_version 372e312e302d7263312b
     3	10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
/usr/bin/kmod 
     4	10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
/usr/lib64/ld64.so.2 
     5	10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
/etc/ld.so.cache 
     6	10 e047868f01908eb95aa180693291decab82bb6be ima-sig
sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
/usr/lib64/libzstd.so.1.5.5 
     7	10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
/usr/lib64/liblzma.so.5.6.2 
     8	10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
/usr/lib64/libz.so.1.3.1.zlib-ng 
     9	10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
/usr/lib64/libcrypto.so.3.5.1 
    10	10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
/usr/lib64/libgcc_s-14-20250617.so.1 
    11	10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
/usr/lib64/glibc-hwcaps/power10/libc.so.6 
    12	10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
/usr/lib/modprobe.d/dist-alsa.conf 
    13	10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
/usr/lib/modprobe.d/dist-blacklist.conf 
    14	10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
/etc/modprobe.d/firewalld-sysctls.conf 
    15	10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
/etc/modprobe.d/l2tp_eth-blacklist.conf 
    16	10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
/etc/modprobe.d/l2tp_ip-blacklist.conf 
    17	10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
/etc/modprobe.d/l2tp_ip6-blacklist.conf 
    18	10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
/etc/modprobe.d/l2tp_netlink-blacklist.conf 
    19	10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
/etc/modprobe.d/l2tp_ppp-blacklist.conf 
    20	10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
/usr/lib/modules/7.1.0-rc1+/modules.softdep 
    21	10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
/etc/modprobe.d/sctp-blacklist.conf 
    22	10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
/etc/modprobe.d/sctp_diag-blacklist.conf 
    23	10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
/usr/lib/modprobe.d/systemd.conf 
    24	10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
/etc/modprobe.d/tipc_diag-blacklist.conf 
    25	10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
/etc/modprobe.d/tuned.conf 
    26	10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
/usr/lib/modules/7.1.0-rc1+/modules.dep.bin 
    27	10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
/usr/lib/modules/7.1.0-rc1+/modules.alias.bin 
    28	10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
/usr/lib/modules/7.1.0-rc1+/modules.symbols.bin 
    29	10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
/usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin 
    30	10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
/usr/lib/modules/7.1.0-rc1+/modules.builtin.bin 
    31	10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate_late 
    32	10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig

Quoted 2 lines

sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e /usr/lib/systemd/systemd

Hmm... Theses measurements seems to happen while populating initramfs which triggers file_post_open as async (and I see the RAMFS seems not part of DONT_MEASURE in IMA).

Quoted 8 lines

If you don't mind, Could you check whether this measurements still happen with initramfs_async=0?

If this measurements aren't generated with above option,
there is a question whether let IMA measure initramfs which can be measured or not depending on boot option or timing (some file measurements could be lost all when do_populate_rootfs() executes concurrently while running late_initcall).

Quoted 4 lines

There's no difference when adding the "initramfs_async=0" boot command line argument. The measurement list between boot_aggregate and boot_aggregate_late is exactly the same.

That's quite interesting. This means there're some file operation between late_initcall and late_initcall_sync
even before run_init_process() except initramfs population.

Quoted 8 lines

Since initramfs population flush all fputs() it generates and boot_aggregate_late is generated before init process is loaded, I honestly have no idea who triggers above file operations.

And it seems a little bit weird that it opens the /usr/bin/kmod and its configuration from kernel not by init_process or other user process...

If you don't mind, Could i get some stacktrace for one of file measurement log between boot_aggregate and boot_aggreate_late?

Though I try to produce like you, I've gotten failure to reproduce. Sorry to bother you. but it would be helpful to understand where they came from.

Quoted 173 lines

Hi Mimi,

Quoted 162 lines

Quoted 153 lines · Yeoreum Yun

Quoted 142 lines

Hi Mimi,

Quoted 133 lines · Yeoreum Yun

Quoted 29 lines

Quoted 23 lines

Quoted 16 lines

Quoted 13 lines

On both Z and PowerVM, there are ~30 measurements between boot_aggregate and boot_aggregate_late. For example, on PowerVM:

# grep -n boot_aggregate
/sys/kernel/security/integrity/ima/ascii_runtime_measurements

1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate
31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5 boot_aggregate_late

Quoted 2 lines

It would be interesting to the results from a Raspberry Pi 5 as well, with/without a TPM.

Quoted 6 lines

Honestly, I find this result hard to accept.

This effectively means that there is code invoking IMA measurement during late_initcall(). It also implies that if, in the future, a late_initcall is added that performs an IMA measurement before IMA initialization has occurred accoding to order by linker, that measurement could be missed.

Quoted 5 lines

Exactly. The results are simply from booting with the builtin "tcb" and "critical_data" policies.

$ sudo grubby --args="ima_policy=\"tcb|critical_data\"" --update-kernel
/boot/vmlinuz-${SUFFIX}

Quoted 8 lines

Thanks. but I still wonder what meaasurements there are between boot_aggregate and boot_aggregate_late.
Might be there would be key measurements if it takes more than 5 mins before generating boot_aggregate_late but this seems rare.

If you don't mind, would you share the contents of the log between boot_aggregate and boot_aggregate_late?
since I only get a kernel_version in my environment.

     1	10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate 
     2	10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
kernel_version 372e312e302d7263312b
     3	10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
/usr/bin/kmod 
     4	10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
/usr/lib64/ld64.so.2 
     5	10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
/etc/ld.so.cache 
     6	10 e047868f01908eb95aa180693291decab82bb6be ima-sig
sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
/usr/lib64/libzstd.so.1.5.5 
     7	10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
/usr/lib64/liblzma.so.5.6.2 
     8	10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
/usr/lib64/libz.so.1.3.1.zlib-ng 
     9	10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
/usr/lib64/libcrypto.so.3.5.1 
    10	10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
/usr/lib64/libgcc_s-14-20250617.so.1 
    11	10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
/usr/lib64/glibc-hwcaps/power10/libc.so.6 
    12	10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
/usr/lib/modprobe.d/dist-alsa.conf 
    13	10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
/usr/lib/modprobe.d/dist-blacklist.conf 
    14	10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
/etc/modprobe.d/firewalld-sysctls.conf 
    15	10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
/etc/modprobe.d/l2tp_eth-blacklist.conf 
    16	10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
/etc/modprobe.d/l2tp_ip-blacklist.conf 
    17	10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
/etc/modprobe.d/l2tp_ip6-blacklist.conf 
    18	10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
/etc/modprobe.d/l2tp_netlink-blacklist.conf 
    19	10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
/etc/modprobe.d/l2tp_ppp-blacklist.conf 
    20	10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
/usr/lib/modules/7.1.0-rc1+/modules.softdep 
    21	10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
/etc/modprobe.d/sctp-blacklist.conf 
    22	10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
/etc/modprobe.d/sctp_diag-blacklist.conf 
    23	10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
/usr/lib/modprobe.d/systemd.conf 
    24	10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
/etc/modprobe.d/tipc_diag-blacklist.conf 
    25	10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
/etc/modprobe.d/tuned.conf 
    26	10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
/usr/lib/modules/7.1.0-rc1+/modules.dep.bin 
    27	10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
/usr/lib/modules/7.1.0-rc1+/modules.alias.bin 
    28	10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
/usr/lib/modules/7.1.0-rc1+/modules.symbols.bin 
    29	10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
/usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin 
    30	10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
/usr/lib/modules/7.1.0-rc1+/modules.builtin.bin 
    31	10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate_late 
    32	10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig

Quoted 2 lines

sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e /usr/lib/systemd/systemd

Hmm... Theses measurements seems to happen while populating initramfs which triggers file_post_open as async (and I see the RAMFS seems not part of DONT_MEASURE in IMA).

Quoted 8 lines

If you don't mind, Could you check whether this measurements still happen with initramfs_async=0?

If this measurements aren't generated with above option,
there is a question whether let IMA measure initramfs which can be measured or not depending on boot option or timing (some file measurements could be lost all when do_populate_rootfs() executes concurrently while running late_initcall).

Quoted 4 lines

There's no difference when adding the "initramfs_async=0" boot command line argument. The measurement list between boot_aggregate and boot_aggregate_late is exactly the same.

That's quite interesting. This means there're some file operation between late_initcall and late_initcall_sync
even before run_init_process() except initramfs population.

Quoted 8 lines

Since initramfs population flush all fputs() it generates and boot_aggregate_late is generated before init process is loaded, I honestly have no idea who triggers above file operations.

And it seems a little bit weird that it opens the /usr/bin/kmod and its configuration from kernel not by init_process or other user process...

Quoted 6 lines

If you don't mind, Could i get some stacktrace for one of file measurement log between boot_aggregate and boot_aggreate_late?

Though I try to produce like you, I've gotten failure to reproduce. Sorry to bother you. but it would be helpful to understand where they came from.

The kernel selftests caused the measurements between late_initcall and late_initcall_sync. After disabling all of the kernel selftests, there weren't any measurements. Re-enabling the FIPS selftests on PowerVM LPAR resulted in measurements. (I didn't try re-enabling any of the other selftests.)

CONFIG_FIPS_SIGNATURE_SELFTEST=y
CONFIG_FIPS_SIGNATURE_SELFTEST_RSA=y
CONFIG_FIPS_SIGNATURE_SELFTEST_ECDSA=y

Quoted 8 lines

The kernel selftests caused the measurements between late_initcall and late_initcall_sync. After disabling all of the kernel selftests, there weren't any measurements. Re-enabling the FIPS selftests on PowerVM LPAR resulted in measurements. (I didn't try re-enabling any of the other selftests.)

CONFIG_FIPS_SIGNATURE_SELFTEST=y
CONFIG_FIPS_SIGNATURE_SELFTEST_RSA=y
CONFIG_FIPS_SIGNATURE_SELFTEST_ECDSA=y

Thanks for shraring this ;)

I found the reason for those mesaurements. Those come from the request_module() and usermode-thread generates them while handling module loading request for crypto-x962(ecdsa-nist-p256).
Since it's not a real kernel module,
I confirmed file measurements between late_initcall and late_initcall_sync are gone for modeprobe with below change:

(quoted diff) +4 -0

@@ -1246,9 +1250,14 @@ EXPORT_SYMBOL_GPL(ima_measure_critical_data);
  */
 static int ima_kernel_module_request(char *kmod_name)
 {
        if (strncmp(kmod_name, "crypto-pkcs1(rsa,", 17) == 0)
                return -EINVAL;
 
+       if (IS_BUILTIN(CONFIG_CRYPTO_ECDSA) &&
+           (strncmp(kmod_name, "crypto-x962(ecdsa", 17) == 0))
+               return -EINVAL;
+
        return 0;
 }
 
 Though this is the only request_module() call between
 late_initcall and late_initcall_sync, but I also confirmed there're
 request_modules() call before ima initalisation before "late_initcall":

/*
* NOTE: kmod_name is printed on ima_kernel_module_request() */

// This is called from module_init(stm_core_init) -> device_initcall() // which is in driver/hwtracing/stm/core.c (built-in)

[    1.421986] ima: kmod_name: stm_p_basic
...
[    1.444900] ima: kmod_name: crypto-pkcs1(rsa,sha512)
[    1.444903] ima: kmod_name: crypto-pkcs1(rsa,sha512)-all
...
[    1.452029] ima: kmod_name: crypto-cbc(aes)
[    1.465321] ima: kmod_name: crypto-cbc(aes)-all
...
[    1.467845] Key type encrypted registered
[    1.467848] AppArmor: AppArmor sha256 policy hashing enabled

// IMA is initailised at late_initcall level.

[    1.467850] ima: [init_ima_late:1336]

If IMA should care request_module() from kernel before IMA init, I think there is no way to solve except queuing those events (kernel_load_data/kernel_load_post_data and open for module binary etc.) though it breaks "measure before use" principle since IMA couldn't measure at that time.

But if you don't care about those things -- some events happend before IMA init, I think your suggestion -- controlling the init time of ima_init() via a Kconfig option is good and ignoring some usermodehelper request including request_module() before IMA initialisation upto user by that option.

Quoted 63 lines

Quoted 9 lines

The kernel selftests caused the measurements between late_initcall and late_initcall_sync. After disabling all of the kernel selftests, there weren't any measurements. Re-enabling the FIPS selftests on PowerVM LPAR resulted in measurements. (I didn't try re-enabling any of the other selftests.)

CONFIG_FIPS_SIGNATURE_SELFTEST=y
CONFIG_FIPS_SIGNATURE_SELFTEST_RSA=y
CONFIG_FIPS_SIGNATURE_SELFTEST_ECDSA=y

Thanks for shraring this ;)

I found the reason for those mesaurements. Those come from the request_module() and usermode-thread generates them while handling module loading request for crypto-x962(ecdsa-nist-p256).
Since it's not a real kernel module,
I confirmed file measurements between late_initcall and late_initcall_sync are gone for modeprobe with below change:

(quoted diff) +4 -0

@@ -1246,9 +1250,14 @@ EXPORT_SYMBOL_GPL(ima_measure_critical_data);
  */
 static int ima_kernel_module_request(char *kmod_name)
 {
        if (strncmp(kmod_name, "crypto-pkcs1(rsa,", 17) == 0)
                return -EINVAL;
 
+       if (IS_BUILTIN(CONFIG_CRYPTO_ECDSA) &&
+           (strncmp(kmod_name, "crypto-x962(ecdsa", 17) == 0))
+               return -EINVAL;
+
        return 0;
 }
 
 Though this is the only request_module() call between
 late_initcall and late_initcall_sync, but I also confirmed there're
 request_modules() call before ima initalisation before "late_initcall":

/*
* NOTE: kmod_name is printed on ima_kernel_module_request() */

// This is called from module_init(stm_core_init) -> device_initcall() // which is in driver/hwtracing/stm/core.c (built-in)

[    1.421986] ima: kmod_name: stm_p_basic
...
[    1.444900] ima: kmod_name: crypto-pkcs1(rsa,sha512)
[    1.444903] ima: kmod_name: crypto-pkcs1(rsa,sha512)-all
...
[    1.452029] ima: kmod_name: crypto-cbc(aes)
[    1.465321] ima: kmod_name: crypto-cbc(aes)-all
...
[    1.467845] Key type encrypted registered
[    1.467848] AppArmor: AppArmor sha256 policy hashing enabled

// IMA is initailised at late_initcall level.

[    1.467850] ima: [init_ima_late:1336]

If IMA should care request_module() from kernel before IMA init, I think there is no way to solve except queuing those events (kernel_load_data/kernel_load_post_data and open for module binary etc.) though it breaks "measure before use" principle since IMA couldn't measure at that time.

Quoted 4 lines

But if you don't care about those things -- some events happend before IMA init, I think your suggestion -- controlling the init time of ima_init() via a Kconfig option is good and ignoring some usermodehelper request including request_module() before IMA initialisation upto user by that option.

Thank you for the complete analysis. The early measurements before the TPM is initialized is a problem that needs to be addressed. As to whether the solution will require queueing is yet to be determined. (Roberto has some thoughts on addressing it.) This discussion makes it clear that simply delaying IMA initialization by moving it from late_initcall to late_initcall_sync could miss measurements. That said, exposing it as an opt-in Kconfig for those who accept the risk is a sensible pragmatic compromise.

Quoted 64 lines · Yeoreum Yun

Quoted 63 lines

Quoted 9 lines

The kernel selftests caused the measurements between late_initcall and late_initcall_sync. After disabling all of the kernel selftests, there weren't any measurements. Re-enabling the FIPS selftests on PowerVM LPAR resulted in measurements. (I didn't try re-enabling any of the other selftests.)

CONFIG_FIPS_SIGNATURE_SELFTEST=y
CONFIG_FIPS_SIGNATURE_SELFTEST_RSA=y
CONFIG_FIPS_SIGNATURE_SELFTEST_ECDSA=y

Thanks for shraring this ;)

I found the reason for those mesaurements. Those come from the request_module() and usermode-thread generates them while handling module loading request for crypto-x962(ecdsa-nist-p256).
Since it's not a real kernel module,
I confirmed file measurements between late_initcall and late_initcall_sync are gone for modeprobe with below change:

(quoted diff) +4 -0

@@ -1246,9 +1250,14 @@ EXPORT_SYMBOL_GPL(ima_measure_critical_data);
  */
 static int ima_kernel_module_request(char *kmod_name)
 {
        if (strncmp(kmod_name, "crypto-pkcs1(rsa,", 17) == 0)
                return -EINVAL;
 
+       if (IS_BUILTIN(CONFIG_CRYPTO_ECDSA) &&
+           (strncmp(kmod_name, "crypto-x962(ecdsa", 17) == 0))
+               return -EINVAL;
+
        return 0;
 }
 
 Though this is the only request_module() call between
 late_initcall and late_initcall_sync, but I also confirmed there're
 request_modules() call before ima initalisation before "late_initcall":

/*
* NOTE: kmod_name is printed on ima_kernel_module_request() */

// This is called from module_init(stm_core_init) -> device_initcall() // which is in driver/hwtracing/stm/core.c (built-in)

[    1.421986] ima: kmod_name: stm_p_basic
...
[    1.444900] ima: kmod_name: crypto-pkcs1(rsa,sha512)
[    1.444903] ima: kmod_name: crypto-pkcs1(rsa,sha512)-all
...
[    1.452029] ima: kmod_name: crypto-cbc(aes)
[    1.465321] ima: kmod_name: crypto-cbc(aes)-all
...
[    1.467845] Key type encrypted registered
[    1.467848] AppArmor: AppArmor sha256 policy hashing enabled

// IMA is initailised at late_initcall level.

[    1.467850] ima: [init_ima_late:1336]

If IMA should care request_module() from kernel before IMA init, I think there is no way to solve except queuing those events (kernel_load_data/kernel_load_post_data and open for module binary etc.) though it breaks "measure before use" principle since IMA couldn't measure at that time.

Quoted 12 lines

Quoted 4 lines

But if you don't care about those things -- some events happend before IMA init, I think your suggestion -- controlling the init time of ima_init() via a Kconfig option is good and ignoring some usermodehelper request including request_module() before IMA initialisation upto user by that option.

Thank you for the complete analysis. The early measurements before the TPM is initialized is a problem that needs to be addressed. As to whether the solution will require queueing is yet to be determined. (Roberto has some thoughts on addressing it.) This discussion makes it clear that simply delaying IMA initialization by moving it from late_initcall to late_initcall_sync could miss measurements. That said, exposing it as an opt-in Kconfig for those who accept the risk is a sensible pragmatic compromise.

I think once we address ealry measurements before intialising TPM, It doesn't matter when IMA is initialissed since they're considered as ealry measurements anyway.

BTW, I'm not sure whether we should take pragmatic compromise first to support deferred TPM initialisation or solving it together via solution of ealry measurements (whatever it is) in now.

I wonder what's going on for discussion to resolve these problem:
1) measurement event (via file operation) before IMA initialisation.
2) deferred TPM device initailisation and IMA.

Might someone could think it wouldn't be a problem since initrd is measuared in PCR9 by boot loader (e.x) grub, but it still has a problem for the case uses root= boot option where it doesn't use initrd but use specified block dev with a filesystem.

I think soluation would be determined whether IMA neglects the measurement event before its initialisation or not in current state:

a) Case for neglecting measurement event before IMA initailisation.

In this case, As you suggeested, IMA initialisation should be determined by build config whether it initialises at late_initcall or late_initcall_sync so that make user can choice upto their platform.

b) Case for considering measurement event event before IMA initialisation.

I couldn't image any other solution except queuing those event and extend them after generating boot_aggregate log and if those event can be queued, it wouldn't a problem to move IMA initialisation to late_initcall_sync.

But you mention there are some thoughts from Roberto, might there was some discussion with him. If you don't mind, would you let me know how the discussion is going on and your thought to fix this all?