Re: [PATCH] ima: debugging late_initcall_sync measurements

[Yeoreum Yun <yeoreum.yun@arm.com>]

> > 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 <zohar@linux.ibm.com> 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/20260417175759.3191279-2-yeoreum.yun@arm.com/
> > > > > 
> > > > > 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