On Thu, Apr 30, 2026 at 9:51 PM Mimi Zohar <[email protected]> wrote: > On Thu, 2026-04-30 at 18:35 -0400, Paul Moore wrote: > > On Thu, Apr 30, 2026 at 5:39 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 > > > > 10 17ec669c65c401e5e85875cf2962eb7d8c47595f ima-ng > > > > sha256:dc6b013e9768d9b13bcd6678470448090138ca831f4771a43ce3988d8e54ffce > > > > /lib/ld-linux-aarch64.so.1 > > > > 10 58679a66ac1de17f02595625a8fbeafa259a4c81 ima-ng > > > > sha256:494f62bcfb2fcf1b427d5092fafa62c8df39a83b4a64402620b28846724f237f > > > > /usr/lib/libtirpc.so.3.0.0 > > > > 10 42f74ee200434576e33be153830b3d55bbe6d2bf ima-ng > > > > sha256:a18856b4f6927bc2b8dd4608c0768b8f98544a161b85bf4a64419131243ad300 > > > > /lib/libresolv.so.2 > > > > 10 626b4f7bd4f123d18d3a3d8719ed0ae19ee5f331 ima-ng > > > > sha256:b8d442de5d31c3f9d1bbb98785f04d4a23dc53442b286d85d4b355927cbe9af4 > > > > /lib/libc.so.6 > > > > 10 655a200869696207646377a58cab417fd35b09d2 ima-ng > > > > sha256:ad46146b6dd32b47213e5327f1bb2f962ef838a4b707ef7445fa2dbc9019b44f > > > > /etc/inittab > > > > 10 81353202685e022fcd0069a3b2fc4eaa6b1db537 ima-ng > > > > sha256:74d698fe0a6862050af29083aa591c960ec1f67be960047e96bb6be5fc2bc0c0 > > > > /bin/mount > > > > 10 ae64184ee607ef8f3aa08ab52cb548318534fd4b ima-ng > > > > sha256:27846b57e8234c6a9611b00351f581a54ad6f9a1920b9aa18ceb0ae28e4f7564 > > > > /lib/libmount.so.1.1.0 > > > > 10 5ea01f34e7705d1bdb936fd576e2aeb5fd78dab9 ima-ng > > > > sha256:3d2a414ec0355fcf0910224fb4a3c53e13d98731a35241edfdf4fb911ed9b210 > > > > /lib/libblkid.so.1.1.0 > > > > 10 22c48b4853594a08a73ad4ae6dbe6f2c2bebc6c5 ima-ng > > > > sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 > > > > /run/utmp > > > > 10 3024ea5021f8a5d9fb4bd519d599bdca43b7fb93 ima-ng > > > > sha256:71ea9ffe2b30e5a9bdceff78785cf281cc41544474db8dc4605a06a597ce1edc > > > > /etc/fstab > > > > 10 2e7530a0f56420991ac7611734cea4774b92b9ef ima-ng > > > > sha256:df4697d699442cfe73db7cc8b4c1b37e8a31e75e01f66a0d70134ac812fa683b > > > > /bin/mkdir > > > > 10 3ad117a863aa1ed7b7c09e1d106f84abf7d2ae96 ima-ng > > > > sha256:c19a710989b43222431b02399273dba409fe10ca8eefff88eaa936fa695f8324 > > > > /bin/ln > > > > 10 4141c82cb516ac3c846e0b08abcd6abeee7efa1a ima-ng > > > > sha256:b75d7f28772f71715a941c77e07e3922815391dd9cc5718ad21f2231c2da09bb > > > > /etc/hostname > > > > 10 dfcedd3c7dc3ed42e09219804504489ab264e2e3 ima-ng > > > > sha256:dc1615df9f2012b20b81ffad8e07e16293039ba7fd897854ca3646d6cfea0c0f > > > > /etc/init.d/rcS > > > > ... > > > > > > > > 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. > > > > Is it not possible to look at the code and determine if it is safe or > > not? Or is the initialization of TPM devices at boot done in a random > > order with respect to the initcall levels? > > The TPM is normally initialized at the device_initcall, except when other > resources are not ready. > > (Abbreviated) AI explanation: > If the TPM's first probe succeeds at device_initcall with no deferral, IMA > finds it fine. It is only when the TPM is pushed onto the deferred list > that > late_initcall can execute before the retry succeeds, leaving > tpm_default_chip() returning NULL.
I really hope you are using AI only to phrase a response and not as a substitute for actually investigating the code and determining what is happening. Regardless, assuming you always want IMA to leverage a TPMs when they exist, your reply suggests that using an initcall based IMA init scheme, even a late-sync initcall, may not be sufficient because deferred TPM initialization could happen later, yes? -- paul-moore.com
