> > On Sun, 2026-05-03 at 07:36 -0400, Mimi Zohar wrote: > > > On Fri, 2026-05-01 at 12:52 -0400, David Safford wrote: > > > > On Thu, Apr 30, 2026 at 5:43 PM Mimi Zohar <[email protected]> wrote: > > > > > > > > > > On Thu, 2026-04-30 at 10:48 +0100, Yeoreum Yun wrote: > > > > > > 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 > > > > > > > > > > > > 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]/ > > > > > > > > > > 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. > > > > > > 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. > > 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?
And since most IMA measurements occur during module, file, or bprm operations, I’m really curious about where such operations take place before the init process is loaded, since init is started only after all initcalls have completed. Personally, I find it hard to believe that this kind of critical data measurement comes from dm or SELinux, as those typically operate via ioctl or load policies after userspace becomes available. If you don’t mind, could you share your test code for the index, as well as some stack traces? That would help me understand where these measurements are coming from. Thanks! > > -- > Sincerely, > Yeoreum Yun > -- Sincerely, Yeoreum Yun
