On Wed, 2026-05-06 at 06:54 +0100, Yeoreum Yun wrote:
> 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.
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}
>
> Could you please check how the index (1, 31) was added to either
> ima_template_entry or ima_queue_entry to produce this result?
The grep "-n" option includes line numbers. It doesn't have anything to do with
the kernel.
Mimi
