Hi Mimi, > 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? -- Sincerely, Yeoreum Yun
