Re: [PATCH] ima: debugging late_initcall_sync measurements

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