Re: [PATCH] ima: debugging late_initcall_sync measurements

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Paul Moore]

On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
> > 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?
>
> Well yeah.  The TPM could be configured as a module, but that scenario is not of
> interest.  That's way too late.  The case being addressed in this patch set is
> when the TPM driver tries to initialize at device_initcall, returns
> EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall).  Since
> ordering within an initcall is not supported, this patch attempts to initialize
> IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.

Okay, so from a TPM initialization perspective you are satisfied with
a late-sync IMA initialization, yes?

-- 
paul-moore.com

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Mimi Zohar]

On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
> On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
> > > 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?
> > 
> > Well yeah.  The TPM could be configured as a module, but that scenario is not of
> > interest.  That's way too late.  The case being addressed in this patch set is
> > when the TPM driver tries to initialize at device_initcall, returns
> > EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall).  Since
> > ordering within an initcall is not supported, this patch attempts to initialize
> > IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.
> 
> Okay, so from a TPM initialization perspective you are satisfied with
> a late-sync IMA initialization, yes?

No. On some architectures moving IMA initialization from the late_initcall to
late_initcall_sync does not miss any measurement records. However, as previously
mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
records[1].  So no, only if the TPM is not initialized by late_initcall, should
IMA retry at late_initcall_sync.

Mimi

[1]
https://lore.kernel.org/linux-integrity/201b9172ac47c6766443c1f2343cab3548f33c29.camel@linux.ibm.com/

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Paul Moore]

On Tue, May 5, 2026 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
> > On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
> > > > 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?
> > >
> > > Well yeah.  The TPM could be configured as a module, but that scenario is not of
> > > interest.  That's way too late.  The case being addressed in this patch set is
> > > when the TPM driver tries to initialize at device_initcall, returns
> > > EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall).  Since
> > > ordering within an initcall is not supported, this patch attempts to initialize
> > > IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.
> >
> > Okay, so from a TPM initialization perspective you are satisfied with
> > a late-sync IMA initialization, yes?
>
> No. On some architectures moving IMA initialization from the late_initcall to
> late_initcall_sync does not miss any measurement records. However, as previously
> mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
> records[1].  So no, only if the TPM is not initialized by late_initcall, should
> IMA retry at late_initcall_sync.

What do you do in the PowerVM LPAR when the TPM is not avaiable at
late initcall and you have to defer IMA initialization until
late-sync?

-- 
paul-moore.com

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Mimi Zohar]

On Tue, 2026-05-05 at 18:55 -0400, Paul Moore wrote:
> On Tue, May 5, 2026 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
> > > On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
> > > > > 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?
> > > > 
> > > > Well yeah.  The TPM could be configured as a module, but that scenario is not of
> > > > interest.  That's way too late.  The case being addressed in this patch set is
> > > > when the TPM driver tries to initialize at device_initcall, returns
> > > > EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall).  Since
> > > > ordering within an initcall is not supported, this patch attempts to initialize
> > > > IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.
> > > 
> > > Okay, so from a TPM initialization perspective you are satisfied with
> > > a late-sync IMA initialization, yes?
> > 
> > No. On some architectures moving IMA initialization from the late_initcall to
> > late_initcall_sync does not miss any measurement records. However, as previously
> > mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
> > records[1].  So no, only if the TPM is not initialized by late_initcall, should
> > IMA retry at late_initcall_sync.
> 
> What do you do in the PowerVM LPAR when the TPM is not avaiable at
> late initcall and you have to defer IMA initialization until
> late-sync?

Your question is hypothetical, as the TPM isn't deferred, so IMA doesn't go into
TPM-bypass mode.  Testing on a PowerVM LPAR demonstrated that it skips ~30
measurement list records.  So moving the initcall to late_initcall_sync would
cause a regression.

Mimi

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Paul Moore]

On May 5, 2026 9:57:23 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Tue, 2026-05-05 at 18:55 -0400, Paul Moore wrote:
>> On Tue, May 5, 2026 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>> On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
>>>> On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>> On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
>>>>>> 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?
>>>>>
>>>>> Well yeah.  The TPM could be configured as a module, but that scenario is 
>>>>> not of
>>>>> interest.  That's way too late.  The case being addressed in this patch set is
>>>>> when the TPM driver tries to initialize at device_initcall, returns
>>>>> EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall).  Since
>>>>> ordering within an initcall is not supported, this patch attempts to initialize
>>>>> IMA at late_initcall and similarly retries, in this case, at 
>>>>> late_initcall_sync.
>>>>
>>>> Okay, so from a TPM initialization perspective you are satisfied with
>>>> a late-sync IMA initialization, yes?
>>>
>>> No. On some architectures moving IMA initialization from the late_initcall to
>>> late_initcall_sync does not miss any measurement records. However, as 
>>> previously
>>> mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
>>> records[1].  So no, only if the TPM is not initialized by late_initcall, should
>>> IMA retry at late_initcall_sync.
>>
>> What do you do in the PowerVM LPAR when the TPM is not avaiable at
>> late initcall and you have to defer IMA initialization until
>> late-sync?
>
> Your question is hypothetical ...

<heavy eye roll>

> ... as the TPM isn't deferred, so IMA doesn't go into
> TPM-bypass mode.  Testing on a PowerVM LPAR demonstrated that it skips ~30
> measurement list records.  So moving the initcall to late_initcall_sync would
> cause a regression.

Let me rephrase to make the question clear - how do you plan to handle a 
system where you lose measurements by waiting until late-sync, but the TPM 
is not available at the late initcall.

--
paul-moore.com

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Mimi Zohar]

On Tue, 2026-05-05 at 22:11 -0400, Paul Moore wrote:
> On May 5, 2026 9:57:23 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Tue, 2026-05-05 at 18:55 -0400, Paul Moore wrote:
> > > On Tue, May 5, 2026 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
> > > > > On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
> > > > > > > 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?
> > > > > > 
> > > > > > Well yeah.  The TPM could be configured as a module, but that scenario is 
> > > > > > not of
> > > > > > interest.  That's way too late.  The case being addressed in this patch set is
> > > > > > when the TPM driver tries to initialize at device_initcall, returns
> > > > > > EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall).  Since
> > > > > > ordering within an initcall is not supported, this patch attempts to initialize
> > > > > > IMA at late_initcall and similarly retries, in this case, at 
> > > > > > late_initcall_sync.
> > > > > 
> > > > > Okay, so from a TPM initialization perspective you are satisfied with
> > > > > a late-sync IMA initialization, yes?
> > > > 
> > > > No. On some architectures moving IMA initialization from the late_initcall to
> > > > late_initcall_sync does not miss any measurement records. However, as 
> > > > previously
> > > > mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
> > > > records[1].  So no, only if the TPM is not initialized by late_initcall, should
> > > > IMA retry at late_initcall_sync.
> > > 
> > > What do you do in the PowerVM LPAR when the TPM is not avaiable at
> > > late initcall and you have to defer IMA initialization until
> > > late-sync?
> > 
> > Your question is hypothetical ...
> 
> <heavy eye roll>
> 
> > ... as the TPM isn't deferred, so IMA doesn't go into
> > TPM-bypass mode.  Testing on a PowerVM LPAR demonstrated that it skips ~30
> > measurement list records.  So moving the initcall to late_initcall_sync would
> > cause a regression.
> 
> Let me rephrase to make the question clear - how do you plan to handle a 
> system where you lose measurements by waiting until late-sync, but the TPM 
> is not available at the late initcall.

There have been suggestions to queue the IMA measurements, but that goes against
the "measure before use" principle. The solution is not to defer IMA
initialization for all systems, but to differentiate the boot_aggregate record
(boot_aggregate vs. boot_aggregate_late) based on when the TPM becomes available
relative to IMA's initcall.  IMA's job is simply to collect and provide the
measurement list.  Based on the attestation service policy, the attestation
service will decide whether a measurement list containing boot_aggregate_late is
acceptable.

Mimi

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Roberto Sassu]

On Wed, 2026-05-06 at 22:25 -0400, Mimi Zohar wrote:
> On Tue, 2026-05-05 at 22:11 -0400, Paul Moore wrote:
> > On May 5, 2026 9:57:23 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > On Tue, 2026-05-05 at 18:55 -0400, Paul Moore wrote:
> > > > On Tue, May 5, 2026 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
> > > > > > On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > > On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
> > > > > > > > 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?
> > > > > > > 
> > > > > > > Well yeah.  The TPM could be configured as a module, but that scenario is 
> > > > > > > not of
> > > > > > > interest.  That's way too late.  The case being addressed in this patch set is
> > > > > > > when the TPM driver tries to initialize at device_initcall, returns
> > > > > > > EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall).  Since
> > > > > > > ordering within an initcall is not supported, this patch attempts to initialize
> > > > > > > IMA at late_initcall and similarly retries, in this case, at 
> > > > > > > late_initcall_sync.
> > > > > > 
> > > > > > Okay, so from a TPM initialization perspective you are satisfied with
> > > > > > a late-sync IMA initialization, yes?
> > > > > 
> > > > > No. On some architectures moving IMA initialization from the late_initcall to
> > > > > late_initcall_sync does not miss any measurement records. However, as 
> > > > > previously
> > > > > mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
> > > > > records[1].  So no, only if the TPM is not initialized by late_initcall, should
> > > > > IMA retry at late_initcall_sync.
> > > > 
> > > > What do you do in the PowerVM LPAR when the TPM is not avaiable at
> > > > late initcall and you have to defer IMA initialization until
> > > > late-sync?
> > > 
> > > Your question is hypothetical ...
> > 
> > <heavy eye roll>
> > 
> > > ... as the TPM isn't deferred, so IMA doesn't go into
> > > TPM-bypass mode.  Testing on a PowerVM LPAR demonstrated that it skips ~30
> > > measurement list records.  So moving the initcall to late_initcall_sync would
> > > cause a regression.
> > 
> > Let me rephrase to make the question clear - how do you plan to handle a 
> > system where you lose measurements by waiting until late-sync, but the TPM 
> > is not available at the late initcall.
> 
> There have been suggestions to queue the IMA measurements, but that goes against
> the "measure before use" principle. The solution is not to defer IMA
> initialization for all systems, but to differentiate the boot_aggregate record
> (boot_aggregate vs. boot_aggregate_late) based on when the TPM becomes available
> relative to IMA's initcall.  IMA's job is simply to collect and provide the
> measurement list.  Based on the attestation service policy, the attestation
> service will decide whether a measurement list containing boot_aggregate_late is
> acceptable.

Agreed on no violation of the measure and load principle.

But also the two boot_aggregate solution does not work. If there are
measurements before boot_aggregate_late, they can corrupt the system
without noticing, and the corrupted system would emit the
boot_aggregate measurement (non-late) to pass verification.

Roberto

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Mimi Zohar]

On Thu, 2026-05-07 at 10:10 +0200, Roberto Sassu wrote:
> On Wed, 2026-05-06 at 22:25 -0400, Mimi Zohar wrote:
> > On Tue, 2026-05-05 at 22:11 -0400, Paul Moore wrote:
> > > On May 5, 2026 9:57:23 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > On Tue, 2026-05-05 at 18:55 -0400, Paul Moore wrote:
> > > > > On Tue, May 5, 2026 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
> > > > > > > On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > > > > > On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
> > > > > > > > > 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?
> > > > > > > > 
> > > > > > > > Well yeah.  The TPM could be configured as a module, but that scenario is 
> > > > > > > > not of
> > > > > > > > interest.  That's way too late.  The case being addressed in this patch set is
> > > > > > > > when the TPM driver tries to initialize at device_initcall, returns
> > > > > > > > EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall).  Since
> > > > > > > > ordering within an initcall is not supported, this patch attempts to initialize
> > > > > > > > IMA at late_initcall and similarly retries, in this case, at 
> > > > > > > > late_initcall_sync.
> > > > > > > 
> > > > > > > Okay, so from a TPM initialization perspective you are satisfied with
> > > > > > > a late-sync IMA initialization, yes?
> > > > > > 
> > > > > > No. On some architectures moving IMA initialization from the late_initcall to
> > > > > > late_initcall_sync does not miss any measurement records. However, as 
> > > > > > previously
> > > > > > mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
> > > > > > records[1].  So no, only if the TPM is not initialized by late_initcall, should
> > > > > > IMA retry at late_initcall_sync.
> > > > > 
> > > > > What do you do in the PowerVM LPAR when the TPM is not avaiable at
> > > > > late initcall and you have to defer IMA initialization until
> > > > > late-sync?
> > > > 
> > > > Your question is hypothetical ...
> > > 
> > > <heavy eye roll>
> > > 
> > > > ... as the TPM isn't deferred, so IMA doesn't go into
> > > > TPM-bypass mode.  Testing on a PowerVM LPAR demonstrated that it skips ~30
> > > > measurement list records.  So moving the initcall to late_initcall_sync would
> > > > cause a regression.
> > > 
> > > Let me rephrase to make the question clear - how do you plan to handle a 
> > > system where you lose measurements by waiting until late-sync, but the TPM 
> > > is not available at the late initcall.
> > 
> > There have been suggestions to queue the IMA measurements, but that goes against
> > the "measure before use" principle. The solution is not to defer IMA
> > initialization for all systems, but to differentiate the boot_aggregate record
> > (boot_aggregate vs. boot_aggregate_late) based on when the TPM becomes available
> > relative to IMA's initcall.  IMA's job is simply to collect and provide the
> > measurement list.  Based on the attestation service policy, the attestation
> > service will decide whether a measurement list containing boot_aggregate_late is
> > acceptable.
> 
> Agreed on no violation of the measure and load principle.
> 
> But also the two boot_aggregate solution does not work. If there are
> measurements before boot_aggregate_late, they can corrupt the system
> without noticing, and the corrupted system would emit the
> boot_aggregate measurement (non-late) to pass verification.

This is a risk management issue. The conservative option is to continue
initializing IMA only at late_initcall, as we have been doing, and accept the
late TPM initialization limitation. The alternative is to also allow IMA to
initialize at late_initcall_sync, controlled by a Kconfig option, so that
existing systems are unaffected while systems with late TPM initialization can
opt in to boot_aggregate_late support.

Mimi

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Yeoreum Yun]

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 <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?

-- 
Sincerely,
Yeoreum Yun

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Yeoreum Yun]

> > 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

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Mimi Zohar]

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 <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.

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

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Yeoreum Yun]

Hi Mimi,

> 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 <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.
> 
> 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}

Thanks. but I still wonder what meaasurements there are between
boot_aggregate and boot_aggregate_late.
Might be there would be key measurements if it takes more than
5 mins before generating boot_aggregate_late but this seems rare.

If you don't mind, would you share the contents of the log between
boot_aggregate and boot_aggregate_late?
since I only get a kernel_version in my environment.

And I think we can collect missing measurements before ima_init_core()
into another separate list than ima_measurements in ima_add_template_entry() and
we can extend them after boot_aggreagate log generation at ima_init_core()
then ima initialisation could be moved to late_initcall_sync like
(just for a test and share concept):

-------&<-------
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 9a1117112fb2..737c1ac8ad77 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -67,6 +67,7 @@ extern int ima_appraise;
 extern struct tpm_chip *ima_tpm_chip;
 extern const char boot_aggregate_name[];
 extern const char boot_aggregate_late_name[];
+extern bool ima_extend_on;

 /* IMA event related data */
 struct ima_event_data {
@@ -107,6 +108,7 @@ struct ima_template_desc {

:...skipping...
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 9a1117112fb2..737c1ac8ad77 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -67,6 +67,7 @@ extern int ima_appraise;
 extern struct tpm_chip *ima_tpm_chip;
 extern const char boot_aggregate_name[];
 extern const char boot_aggregate_late_name[];
+extern bool ima_extend_on;

 /* IMA event related data */
 struct ima_event_data {
@@ -107,6 +108,7 @@ struct ima_template_desc {

 struct ima_template_entry {
        int pcr;
+       int violation;
        struct tpm_digest *digests;
        struct ima_template_desc *template_desc; /* template descriptor */
        u32 template_data_len;
@@ -317,6 +319,7 @@ unsigned long ima_get_binary_runtime_size(void);
 int ima_init_template(void);
 void ima_init_template_list(void);
 int __init ima_init_digests(void);
+int __init ima_extend_deferred(void);
 void __init ima_init_reboot_notifier(void);
 int ima_lsm_policy_change(struct notifier_block *nb, unsigned long event,
                          void *lsm_data);
diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c
index edd063b99685..f6a2b53c1dcb 100644
--- a/security/integrity/ima/ima_init.c
+++ b/security/integrity/ima/ima_init.c
@@ -149,10 +149,22 @@ int __init ima_init_core(bool late)
        rc = ima_init_digests();
        if (rc != 0)
                return rc;
+
+       ima_extend_on = true;
+
        rc = ima_add_boot_aggregate(late);      /* boot aggregate must be first entry */
        if (rc != 0)
                return rc;

+       /* This is just for a test. */
+       if (!late)
+               ima_extend_on = false;
+       else  {
+               rc = ima_extend_deferred();
+               if (rc != 0)
+                       return rc;
+       }
+
        ima_init_policy();

        rc = ima_fs_init();
diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
index 319522450854..81f2ee070fee 100644
--- a/security/integrity/ima/ima_queue.c
+++ b/security/integrity/ima/ima_queue.c
@@ -22,10 +22,13 @@

 #define AUDIT_CAUSE_LEN_MAX 32

+bool ima_extend_on;
+
 /* pre-allocated array of tpm_digest structures to extend a PCR */
 static struct tpm_digest *digests;

 LIST_HEAD(ima_measurements);   /* list of all measurements */
+static LIST_HEAD(ima_extend_deferred_head);
 #ifdef CONFIG_IMA_KEXEC
 static unsigned long binary_runtime_size;
 #else
@@ -91,6 +94,7 @@ static int get_binary_runtime_size(struct ima_template_entry *entry)
        return size;
 }

+
 /* ima_add_template_entry helper function:
  * - Add template entry to the measurement list and hash table, for
  *   all entries except those carried across kexec.
@@ -98,7 +102,8 @@ static int get_binary_runtime_size(struct ima_template_entry *entry)
  * (Called with ima_extend_list_mutex held.)
  */
 static int ima_add_digest_entry(struct ima_template_entry *entry,
-                               bool update_htable)
+                               bool update_htable,
+                               struct list_head *measurements_list)
 {
        struct ima_queue_entry *qe;
        unsigned int key;
@@ -111,7 +116,7 @@ static int ima_add_digest_entry(struct ima_template_entry *entry,
        qe->entry = entry;

        INIT_LIST_HEAD(&qe->later);
-       list_add_tail_rcu(&qe->later, &ima_measurements);
+       list_add_tail_rcu(&qe->later, measurements_list);

        atomic_long_inc(&ima_htable.len);
        if (update_htable) {
@@ -173,6 +178,7 @@ int ima_add_template_entry(struct ima_template_entry *entry, int violation,
        char tpm_audit_cause[AUDIT_CAUSE_LEN_MAX];
        int audit_info = 1;
        int result = 0, tpmresult = 0;
+       struct list_head *measurements_list;

        mutex_lock(&ima_extend_list_mutex);

@@ -195,15 +201,21 @@ int ima_add_template_entry(struct ima_template_entry *entry, int violation,
                }
        }

+
+       entry->violation = violation;
+       measurements_list = (ima_extend_on) ? &ima_measurements :
+                                             &ima_extend_deferred_head;
+
        result = ima_add_digest_entry(entry,
-                                     !IS_ENABLED(CONFIG_IMA_DISABLE_HTABLE));
+                                     !IS_ENABLED(CONFIG_IMA_DISABLE_HTABLE),
+                                     measurements_list);
        if (result < 0) {
                audit_cause = "ENOMEM";
                audit_info = 0;
                goto out;
        }

-       if (violation)          /* invalidate pcr */
+       if (violation)                  /* invalidate pcr */
                digests_arg = digests;

        tpmresult = ima_pcr_extend(digests_arg, entry->pcr);
@@ -225,7 +237,7 @@ int ima_restore_measurement_entry(struct ima_template_entry *entry)
        int result = 0;

        mutex_lock(&ima_extend_list_mutex);
-       result = ima_add_digest_entry(entry, 0);
+       result = ima_add_digest_entry(entry, 0, &ima_measurements);
        mutex_unlock(&ima_extend_list_mutex);
        return result;
 }
@@ -288,3 +300,23 @@ int __init ima_init_digests(void)

        return 0;
 }
+
+int __init ima_extend_deferred(void)
+{
+       guard(mutex)(&ima_extend_list_mutex);
+       struct ima_queue_entry *qe;
+       struct tpm_digest *digests_arg;
+       int ret = 0;
+
+       list_for_each_entry(qe, &ima_extend_deferred_head, later) {
+               digests_arg = (qe->entry->violation) ? digests : qe->entry->digests;
+               ret = ima_pcr_extend(digests_arg, qe->entry->pcr);
+               if (ret)
+                       /* TODO: audit? */
+                       break;
+       }
+
+       list_splice_tail_init(&ima_extend_deferred_head, &ima_measurements);
+
+       return ret;
+}

-- 
Sincerely,
Yeoreum Yun

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Mimi Zohar]

On Wed, 2026-05-06 at 14:57 +0100, Yeoreum Yun wrote:
> > > > 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}
> 
> Thanks. but I still wonder what meaasurements there are between
> boot_aggregate and boot_aggregate_late.
> Might be there would be key measurements if it takes more than
> 5 mins before generating boot_aggregate_late but this seems rare.
> 
> If you don't mind, would you share the contents of the log between
> boot_aggregate and boot_aggregate_late?
> since I only get a kernel_version in my environment.

     1	10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate 
     2	10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
kernel_version 372e312e302d7263312b
     3	10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
/usr/bin/kmod 
     4	10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
/usr/lib64/ld64.so.2 
     5	10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
/etc/ld.so.cache 
     6	10 e047868f01908eb95aa180693291decab82bb6be ima-sig
sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
/usr/lib64/libzstd.so.1.5.5 
     7	10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
/usr/lib64/liblzma.so.5.6.2 
     8	10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
/usr/lib64/libz.so.1.3.1.zlib-ng 
     9	10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
/usr/lib64/libcrypto.so.3.5.1 
    10	10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
/usr/lib64/libgcc_s-14-20250617.so.1 
    11	10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
/usr/lib64/glibc-hwcaps/power10/libc.so.6 
    12	10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
/usr/lib/modprobe.d/dist-alsa.conf 
    13	10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
/usr/lib/modprobe.d/dist-blacklist.conf 
    14	10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
/etc/modprobe.d/firewalld-sysctls.conf 
    15	10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
/etc/modprobe.d/l2tp_eth-blacklist.conf 
    16	10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
/etc/modprobe.d/l2tp_ip-blacklist.conf 
    17	10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
/etc/modprobe.d/l2tp_ip6-blacklist.conf 
    18	10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
/etc/modprobe.d/l2tp_netlink-blacklist.conf 
    19	10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
/etc/modprobe.d/l2tp_ppp-blacklist.conf 
    20	10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
/usr/lib/modules/7.1.0-rc1+/modules.softdep 
    21	10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
/etc/modprobe.d/sctp-blacklist.conf 
    22	10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
/etc/modprobe.d/sctp_diag-blacklist.conf 
    23	10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
/usr/lib/modprobe.d/systemd.conf 
    24	10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
/etc/modprobe.d/tipc_diag-blacklist.conf 
    25	10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
/etc/modprobe.d/tuned.conf 
    26	10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
/usr/lib/modules/7.1.0-rc1+/modules.dep.bin 
    27	10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
/usr/lib/modules/7.1.0-rc1+/modules.alias.bin 
    28	10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
/usr/lib/modules/7.1.0-rc1+/modules.symbols.bin 
    29	10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
/usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin 
    30	10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
/usr/lib/modules/7.1.0-rc1+/modules.builtin.bin 
    31	10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
boot_aggregate_late 
    32	10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig
sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e
/usr/lib/systemd/systemd 

> 
> And I think we can collect missing measurements before ima_init_core()
> into another separate list than ima_measurements in ima_add_template_entry() and
> we can extend them after boot_aggreagate log generation at ima_init_core()
> then ima initialisation could be moved to late_initcall_sync like
> (just for a test and share concept):

That breaks the "measure before use" principle.

Mimi

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Yeoreum Yun]

Hi Mimi,

> On Wed, 2026-05-06 at 14:57 +0100, Yeoreum Yun wrote:
> > > > > 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}
> > 
> > Thanks. but I still wonder what meaasurements there are between
> > boot_aggregate and boot_aggregate_late.
> > Might be there would be key measurements if it takes more than
> > 5 mins before generating boot_aggregate_late but this seems rare.
> > 
> > If you don't mind, would you share the contents of the log between
> > boot_aggregate and boot_aggregate_late?
> > since I only get a kernel_version in my environment.
> 
>      1	10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> boot_aggregate 
>      2	10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
> sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
> kernel_version 372e312e302d7263312b
>      3	10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
> sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
> /usr/bin/kmod 
>      4	10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
> sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
> /usr/lib64/ld64.so.2 
>      5	10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
> sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
> /etc/ld.so.cache 
>      6	10 e047868f01908eb95aa180693291decab82bb6be ima-sig
> sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
> /usr/lib64/libzstd.so.1.5.5 
>      7	10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
> sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
> /usr/lib64/liblzma.so.5.6.2 
>      8	10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
> sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
> /usr/lib64/libz.so.1.3.1.zlib-ng 
>      9	10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
> sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
> /usr/lib64/libcrypto.so.3.5.1 
>     10	10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
> sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
> /usr/lib64/libgcc_s-14-20250617.so.1 
>     11	10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
> sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
> /usr/lib64/glibc-hwcaps/power10/libc.so.6 
>     12	10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
> sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
> /usr/lib/modprobe.d/dist-alsa.conf 
>     13	10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
> sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
> /usr/lib/modprobe.d/dist-blacklist.conf 
>     14	10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
> sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
> /etc/modprobe.d/firewalld-sysctls.conf 
>     15	10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
> sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
> /etc/modprobe.d/l2tp_eth-blacklist.conf 
>     16	10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
> sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
> /etc/modprobe.d/l2tp_ip-blacklist.conf 
>     17	10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
> sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
> /etc/modprobe.d/l2tp_ip6-blacklist.conf 
>     18	10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
> sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
> /etc/modprobe.d/l2tp_netlink-blacklist.conf 
>     19	10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
> sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
> /etc/modprobe.d/l2tp_ppp-blacklist.conf 
>     20	10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
> sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
> /usr/lib/modules/7.1.0-rc1+/modules.softdep 
>     21	10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
> sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
> /etc/modprobe.d/sctp-blacklist.conf 
>     22	10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
> sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
> /etc/modprobe.d/sctp_diag-blacklist.conf 
>     23	10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
> sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
> /usr/lib/modprobe.d/systemd.conf 
>     24	10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
> sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
> /etc/modprobe.d/tipc_diag-blacklist.conf 
>     25	10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
> sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
> /etc/modprobe.d/tuned.conf 
>     26	10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
> sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
> /usr/lib/modules/7.1.0-rc1+/modules.dep.bin 
>     27	10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
> sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
> /usr/lib/modules/7.1.0-rc1+/modules.alias.bin 
>     28	10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
> sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
> /usr/lib/modules/7.1.0-rc1+/modules.symbols.bin 
>     29	10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
> sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
> /usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin 
>     30	10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
> sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
> /usr/lib/modules/7.1.0-rc1+/modules.builtin.bin 
>     31	10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> boot_aggregate_late 
>     32	10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig
> sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e
> /usr/lib/systemd/systemd 

Hmm... Theses measurements seems to happen while populating
initramfs which triggers file_post_open as async
(and I see the RAMFS seems not part of DONT_MEASURE in IMA).

If you don't mind, Could you check whether this measurements still
happen with initramfs_async=0?

If this measurements aren't generated with above option,
there is a question whether let IMA measure initramfs which can be
measured or not depending on boot option or timing (some file measurements
could be lost all when do_populate_rootfs() executes concurrently while
running late_initcall).


[...]

-- 
Sincerely,
Yeoreum Yun

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Mimi Zohar]

On Thu, 2026-05-07 at 06:50 +0100, Yeoreum Yun wrote:
> Hi Mimi,
> 
> > On Wed, 2026-05-06 at 14:57 +0100, Yeoreum Yun wrote:
> > > > > > 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}
> > > 
> > > Thanks. but I still wonder what meaasurements there are between
> > > boot_aggregate and boot_aggregate_late.
> > > Might be there would be key measurements if it takes more than
> > > 5 mins before generating boot_aggregate_late but this seems rare.
> > > 
> > > If you don't mind, would you share the contents of the log between
> > > boot_aggregate and boot_aggregate_late?
> > > since I only get a kernel_version in my environment.
> > 
> >      1	10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > boot_aggregate 
> >      2	10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
> > sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
> > kernel_version 372e312e302d7263312b
> >      3	10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
> > sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
> > /usr/bin/kmod 
> >      4	10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
> > sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
> > /usr/lib64/ld64.so.2 
> >      5	10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
> > sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
> > /etc/ld.so.cache 
> >      6	10 e047868f01908eb95aa180693291decab82bb6be ima-sig
> > sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
> > /usr/lib64/libzstd.so.1.5.5 
> >      7	10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
> > sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
> > /usr/lib64/liblzma.so.5.6.2 
> >      8	10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
> > sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
> > /usr/lib64/libz.so.1.3.1.zlib-ng 
> >      9	10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
> > sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
> > /usr/lib64/libcrypto.so.3.5.1 
> >     10	10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
> > sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
> > /usr/lib64/libgcc_s-14-20250617.so.1 
> >     11	10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
> > sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
> > /usr/lib64/glibc-hwcaps/power10/libc.so.6 
> >     12	10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
> > sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
> > /usr/lib/modprobe.d/dist-alsa.conf 
> >     13	10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
> > sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
> > /usr/lib/modprobe.d/dist-blacklist.conf 
> >     14	10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
> > sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
> > /etc/modprobe.d/firewalld-sysctls.conf 
> >     15	10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
> > sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
> > /etc/modprobe.d/l2tp_eth-blacklist.conf 
> >     16	10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
> > sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
> > /etc/modprobe.d/l2tp_ip-blacklist.conf 
> >     17	10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
> > sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
> > /etc/modprobe.d/l2tp_ip6-blacklist.conf 
> >     18	10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
> > sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
> > /etc/modprobe.d/l2tp_netlink-blacklist.conf 
> >     19	10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
> > sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
> > /etc/modprobe.d/l2tp_ppp-blacklist.conf 
> >     20	10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
> > sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
> > /usr/lib/modules/7.1.0-rc1+/modules.softdep 
> >     21	10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
> > sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
> > /etc/modprobe.d/sctp-blacklist.conf 
> >     22	10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
> > sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
> > /etc/modprobe.d/sctp_diag-blacklist.conf 
> >     23	10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
> > sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
> > /usr/lib/modprobe.d/systemd.conf 
> >     24	10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
> > sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
> > /etc/modprobe.d/tipc_diag-blacklist.conf 
> >     25	10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
> > sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
> > /etc/modprobe.d/tuned.conf 
> >     26	10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
> > sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
> > /usr/lib/modules/7.1.0-rc1+/modules.dep.bin 
> >     27	10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
> > sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
> > /usr/lib/modules/7.1.0-rc1+/modules.alias.bin 
> >     28	10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
> > sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
> > /usr/lib/modules/7.1.0-rc1+/modules.symbols.bin 
> >     29	10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
> > sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
> > /usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin 
> >     30	10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
> > sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
> > /usr/lib/modules/7.1.0-rc1+/modules.builtin.bin 
> >     31	10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > boot_aggregate_late 
> >     32	10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig
> > sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e
> > /usr/lib/systemd/systemd 
> 
> Hmm... Theses measurements seems to happen while populating
> initramfs which triggers file_post_open as async
> (and I see the RAMFS seems not part of DONT_MEASURE in IMA).
> 
> If you don't mind, Could you check whether this measurements still
> happen with initramfs_async=0?
> 
> If this measurements aren't generated with above option,
> there is a question whether let IMA measure initramfs which can be
> measured or not depending on boot option or timing (some file measurements
> could be lost all when do_populate_rootfs() executes concurrently while
> running late_initcall).

There's no difference when adding the "initramfs_async=0" boot command line
argument. The measurement list between boot_aggregate and boot_aggregate_late is
exactly the same.

Mimi

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Yeoreum Yun]

Hi Mimi,

> On Thu, 2026-05-07 at 06:50 +0100, Yeoreum Yun wrote:
> > Hi Mimi,
> > 
> > > On Wed, 2026-05-06 at 14:57 +0100, Yeoreum Yun wrote:
> > > > > > > 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}
> > > > 
> > > > Thanks. but I still wonder what meaasurements there are between
> > > > boot_aggregate and boot_aggregate_late.
> > > > Might be there would be key measurements if it takes more than
> > > > 5 mins before generating boot_aggregate_late but this seems rare.
> > > > 
> > > > If you don't mind, would you share the contents of the log between
> > > > boot_aggregate and boot_aggregate_late?
> > > > since I only get a kernel_version in my environment.
> > > 
> > >      1	10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > boot_aggregate 
> > >      2	10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
> > > sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
> > > kernel_version 372e312e302d7263312b
> > >      3	10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
> > > sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
> > > /usr/bin/kmod 
> > >      4	10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
> > > sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
> > > /usr/lib64/ld64.so.2 
> > >      5	10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
> > > sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
> > > /etc/ld.so.cache 
> > >      6	10 e047868f01908eb95aa180693291decab82bb6be ima-sig
> > > sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
> > > /usr/lib64/libzstd.so.1.5.5 
> > >      7	10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
> > > sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
> > > /usr/lib64/liblzma.so.5.6.2 
> > >      8	10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
> > > sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
> > > /usr/lib64/libz.so.1.3.1.zlib-ng 
> > >      9	10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
> > > sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
> > > /usr/lib64/libcrypto.so.3.5.1 
> > >     10	10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
> > > sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
> > > /usr/lib64/libgcc_s-14-20250617.so.1 
> > >     11	10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
> > > sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
> > > /usr/lib64/glibc-hwcaps/power10/libc.so.6 
> > >     12	10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
> > > sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
> > > /usr/lib/modprobe.d/dist-alsa.conf 
> > >     13	10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
> > > sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
> > > /usr/lib/modprobe.d/dist-blacklist.conf 
> > >     14	10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
> > > sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
> > > /etc/modprobe.d/firewalld-sysctls.conf 
> > >     15	10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
> > > sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
> > > /etc/modprobe.d/l2tp_eth-blacklist.conf 
> > >     16	10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
> > > sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
> > > /etc/modprobe.d/l2tp_ip-blacklist.conf 
> > >     17	10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
> > > sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
> > > /etc/modprobe.d/l2tp_ip6-blacklist.conf 
> > >     18	10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
> > > sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
> > > /etc/modprobe.d/l2tp_netlink-blacklist.conf 
> > >     19	10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
> > > sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
> > > /etc/modprobe.d/l2tp_ppp-blacklist.conf 
> > >     20	10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
> > > sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
> > > /usr/lib/modules/7.1.0-rc1+/modules.softdep 
> > >     21	10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
> > > sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
> > > /etc/modprobe.d/sctp-blacklist.conf 
> > >     22	10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
> > > sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
> > > /etc/modprobe.d/sctp_diag-blacklist.conf 
> > >     23	10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
> > > sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
> > > /usr/lib/modprobe.d/systemd.conf 
> > >     24	10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
> > > sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
> > > /etc/modprobe.d/tipc_diag-blacklist.conf 
> > >     25	10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
> > > sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
> > > /etc/modprobe.d/tuned.conf 
> > >     26	10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
> > > sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
> > > /usr/lib/modules/7.1.0-rc1+/modules.dep.bin 
> > >     27	10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
> > > sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
> > > /usr/lib/modules/7.1.0-rc1+/modules.alias.bin 
> > >     28	10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
> > > sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
> > > /usr/lib/modules/7.1.0-rc1+/modules.symbols.bin 
> > >     29	10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
> > > sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
> > > /usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin 
> > >     30	10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
> > > sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
> > > /usr/lib/modules/7.1.0-rc1+/modules.builtin.bin 
> > >     31	10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > boot_aggregate_late 
> > >     32	10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig
> > > sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e
> > > /usr/lib/systemd/systemd 
> > 
> > Hmm... Theses measurements seems to happen while populating
> > initramfs which triggers file_post_open as async
> > (and I see the RAMFS seems not part of DONT_MEASURE in IMA).
> > 
> > If you don't mind, Could you check whether this measurements still
> > happen with initramfs_async=0?
> > 
> > If this measurements aren't generated with above option,
> > there is a question whether let IMA measure initramfs which can be
> > measured or not depending on boot option or timing (some file measurements
> > could be lost all when do_populate_rootfs() executes concurrently while
> > running late_initcall).
> 
> There's no difference when adding the "initramfs_async=0" boot command line
> argument. The measurement list between boot_aggregate and boot_aggregate_late is
> exactly the same.
>

That's quite interesting. This means there're some file operation
between late_initcall and late_initcall_sync
even before run_init_process() except initramfs population.

Since initramfs population flush all fputs() it generates and
boot_aggregate_late is generated before init process is loaded,
I honestly have no idea who triggers above file operations.

And it seems a little bit weird that it opens the /usr/bin/kmod
and its configuration from kernel not by init_process or other user
process...

-- 
Sincerely,
Yeoreum Yun

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Yeoreum Yun]

Hi Mimi,

> 
> > On Thu, 2026-05-07 at 06:50 +0100, Yeoreum Yun wrote:
> > > Hi Mimi,
> > > 
> > > > On Wed, 2026-05-06 at 14:57 +0100, Yeoreum Yun wrote:
> > > > > > > > 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}
> > > > > 
> > > > > Thanks. but I still wonder what meaasurements there are between
> > > > > boot_aggregate and boot_aggregate_late.
> > > > > Might be there would be key measurements if it takes more than
> > > > > 5 mins before generating boot_aggregate_late but this seems rare.
> > > > > 
> > > > > If you don't mind, would you share the contents of the log between
> > > > > boot_aggregate and boot_aggregate_late?
> > > > > since I only get a kernel_version in my environment.
> > > > 
> > > >      1	10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> > > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > > boot_aggregate 
> > > >      2	10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
> > > > sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
> > > > kernel_version 372e312e302d7263312b
> > > >      3	10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
> > > > sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
> > > > /usr/bin/kmod 
> > > >      4	10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
> > > > sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
> > > > /usr/lib64/ld64.so.2 
> > > >      5	10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
> > > > sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
> > > > /etc/ld.so.cache 
> > > >      6	10 e047868f01908eb95aa180693291decab82bb6be ima-sig
> > > > sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
> > > > /usr/lib64/libzstd.so.1.5.5 
> > > >      7	10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
> > > > sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
> > > > /usr/lib64/liblzma.so.5.6.2 
> > > >      8	10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
> > > > sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
> > > > /usr/lib64/libz.so.1.3.1.zlib-ng 
> > > >      9	10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
> > > > sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
> > > > /usr/lib64/libcrypto.so.3.5.1 
> > > >     10	10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
> > > > sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
> > > > /usr/lib64/libgcc_s-14-20250617.so.1 
> > > >     11	10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
> > > > sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
> > > > /usr/lib64/glibc-hwcaps/power10/libc.so.6 
> > > >     12	10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
> > > > sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
> > > > /usr/lib/modprobe.d/dist-alsa.conf 
> > > >     13	10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
> > > > sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
> > > > /usr/lib/modprobe.d/dist-blacklist.conf 
> > > >     14	10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
> > > > sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
> > > > /etc/modprobe.d/firewalld-sysctls.conf 
> > > >     15	10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
> > > > sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
> > > > /etc/modprobe.d/l2tp_eth-blacklist.conf 
> > > >     16	10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
> > > > sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
> > > > /etc/modprobe.d/l2tp_ip-blacklist.conf 
> > > >     17	10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
> > > > sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
> > > > /etc/modprobe.d/l2tp_ip6-blacklist.conf 
> > > >     18	10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
> > > > sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
> > > > /etc/modprobe.d/l2tp_netlink-blacklist.conf 
> > > >     19	10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
> > > > sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
> > > > /etc/modprobe.d/l2tp_ppp-blacklist.conf 
> > > >     20	10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
> > > > sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
> > > > /usr/lib/modules/7.1.0-rc1+/modules.softdep 
> > > >     21	10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
> > > > sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
> > > > /etc/modprobe.d/sctp-blacklist.conf 
> > > >     22	10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
> > > > sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
> > > > /etc/modprobe.d/sctp_diag-blacklist.conf 
> > > >     23	10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
> > > > sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
> > > > /usr/lib/modprobe.d/systemd.conf 
> > > >     24	10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
> > > > sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
> > > > /etc/modprobe.d/tipc_diag-blacklist.conf 
> > > >     25	10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
> > > > sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
> > > > /etc/modprobe.d/tuned.conf 
> > > >     26	10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
> > > > sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
> > > > /usr/lib/modules/7.1.0-rc1+/modules.dep.bin 
> > > >     27	10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
> > > > sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
> > > > /usr/lib/modules/7.1.0-rc1+/modules.alias.bin 
> > > >     28	10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
> > > > sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
> > > > /usr/lib/modules/7.1.0-rc1+/modules.symbols.bin 
> > > >     29	10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
> > > > sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
> > > > /usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin 
> > > >     30	10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
> > > > sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
> > > > /usr/lib/modules/7.1.0-rc1+/modules.builtin.bin 
> > > >     31	10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> > > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > > boot_aggregate_late 
> > > >     32	10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig
> > > > sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e
> > > > /usr/lib/systemd/systemd 
> > > 
> > > Hmm... Theses measurements seems to happen while populating
> > > initramfs which triggers file_post_open as async
> > > (and I see the RAMFS seems not part of DONT_MEASURE in IMA).
> > > 
> > > If you don't mind, Could you check whether this measurements still
> > > happen with initramfs_async=0?
> > > 
> > > If this measurements aren't generated with above option,
> > > there is a question whether let IMA measure initramfs which can be
> > > measured or not depending on boot option or timing (some file measurements
> > > could be lost all when do_populate_rootfs() executes concurrently while
> > > running late_initcall).
> > 
> > There's no difference when adding the "initramfs_async=0" boot command line
> > argument. The measurement list between boot_aggregate and boot_aggregate_late is
> > exactly the same.
> >
> 
> That's quite interesting. This means there're some file operation
> between late_initcall and late_initcall_sync
> even before run_init_process() except initramfs population.
> 
> Since initramfs population flush all fputs() it generates and
> boot_aggregate_late is generated before init process is loaded,
> I honestly have no idea who triggers above file operations.
> 
> And it seems a little bit weird that it opens the /usr/bin/kmod
> and its configuration from kernel not by init_process or other user
> process...
> 

If you don't mind, Could i get some stacktrace for one of file measurement log
between boot_aggregate and boot_aggreate_late?

Though I try to produce like you, I've gotten failure to reproduce.
Sorry to bother you. but it would be helpful to understand where they
came from.

-- 
Sincerely,
Yeoreum Yun

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Mimi Zohar]

On Thu, 2026-05-07 at 21:03 +0100, Yeoreum Yun wrote:
> Hi Mimi,
> 
> > 
> > > On Thu, 2026-05-07 at 06:50 +0100, Yeoreum Yun wrote:
> > > > Hi Mimi,
> > > > 
> > > > > On Wed, 2026-05-06 at 14:57 +0100, Yeoreum Yun wrote:
> > > > > > > > > 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}
> > > > > > 
> > > > > > Thanks. but I still wonder what meaasurements there are between
> > > > > > boot_aggregate and boot_aggregate_late.
> > > > > > Might be there would be key measurements if it takes more than
> > > > > > 5 mins before generating boot_aggregate_late but this seems rare.
> > > > > > 
> > > > > > If you don't mind, would you share the contents of the log between
> > > > > > boot_aggregate and boot_aggregate_late?
> > > > > > since I only get a kernel_version in my environment.
> > > > > 
> > > > >      1	10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> > > > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > > > boot_aggregate 
> > > > >      2	10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
> > > > > sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
> > > > > kernel_version 372e312e302d7263312b
> > > > >      3	10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
> > > > > sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
> > > > > /usr/bin/kmod 
> > > > >      4	10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
> > > > > sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
> > > > > /usr/lib64/ld64.so.2 
> > > > >      5	10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
> > > > > sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
> > > > > /etc/ld.so.cache 
> > > > >      6	10 e047868f01908eb95aa180693291decab82bb6be ima-sig
> > > > > sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
> > > > > /usr/lib64/libzstd.so.1.5.5 
> > > > >      7	10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
> > > > > sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
> > > > > /usr/lib64/liblzma.so.5.6.2 
> > > > >      8	10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
> > > > > sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
> > > > > /usr/lib64/libz.so.1.3.1.zlib-ng 
> > > > >      9	10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
> > > > > sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
> > > > > /usr/lib64/libcrypto.so.3.5.1 
> > > > >     10	10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
> > > > > sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
> > > > > /usr/lib64/libgcc_s-14-20250617.so.1 
> > > > >     11	10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
> > > > > sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
> > > > > /usr/lib64/glibc-hwcaps/power10/libc.so.6 
> > > > >     12	10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
> > > > > sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
> > > > > /usr/lib/modprobe.d/dist-alsa.conf 
> > > > >     13	10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
> > > > > sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
> > > > > /usr/lib/modprobe.d/dist-blacklist.conf 
> > > > >     14	10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
> > > > > sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
> > > > > /etc/modprobe.d/firewalld-sysctls.conf 
> > > > >     15	10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
> > > > > sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
> > > > > /etc/modprobe.d/l2tp_eth-blacklist.conf 
> > > > >     16	10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
> > > > > sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
> > > > > /etc/modprobe.d/l2tp_ip-blacklist.conf 
> > > > >     17	10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
> > > > > sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
> > > > > /etc/modprobe.d/l2tp_ip6-blacklist.conf 
> > > > >     18	10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
> > > > > sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
> > > > > /etc/modprobe.d/l2tp_netlink-blacklist.conf 
> > > > >     19	10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
> > > > > sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
> > > > > /etc/modprobe.d/l2tp_ppp-blacklist.conf 
> > > > >     20	10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
> > > > > sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
> > > > > /usr/lib/modules/7.1.0-rc1+/modules.softdep 
> > > > >     21	10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
> > > > > sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
> > > > > /etc/modprobe.d/sctp-blacklist.conf 
> > > > >     22	10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
> > > > > sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
> > > > > /etc/modprobe.d/sctp_diag-blacklist.conf 
> > > > >     23	10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
> > > > > sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
> > > > > /usr/lib/modprobe.d/systemd.conf 
> > > > >     24	10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
> > > > > sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
> > > > > /etc/modprobe.d/tipc_diag-blacklist.conf 
> > > > >     25	10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
> > > > > sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
> > > > > /etc/modprobe.d/tuned.conf 
> > > > >     26	10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
> > > > > sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
> > > > > /usr/lib/modules/7.1.0-rc1+/modules.dep.bin 
> > > > >     27	10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
> > > > > sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
> > > > > /usr/lib/modules/7.1.0-rc1+/modules.alias.bin 
> > > > >     28	10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
> > > > > sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
> > > > > /usr/lib/modules/7.1.0-rc1+/modules.symbols.bin 
> > > > >     29	10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
> > > > > sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
> > > > > /usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin 
> > > > >     30	10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
> > > > > sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
> > > > > /usr/lib/modules/7.1.0-rc1+/modules.builtin.bin 
> > > > >     31	10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> > > > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > > > boot_aggregate_late 
> > > > >     32	10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig
> > > > > sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e
> > > > > /usr/lib/systemd/systemd 
> > > > 
> > > > Hmm... Theses measurements seems to happen while populating
> > > > initramfs which triggers file_post_open as async
> > > > (and I see the RAMFS seems not part of DONT_MEASURE in IMA).
> > > > 
> > > > If you don't mind, Could you check whether this measurements still
> > > > happen with initramfs_async=0?
> > > > 
> > > > If this measurements aren't generated with above option,
> > > > there is a question whether let IMA measure initramfs which can be
> > > > measured or not depending on boot option or timing (some file measurements
> > > > could be lost all when do_populate_rootfs() executes concurrently while
> > > > running late_initcall).
> > > 
> > > There's no difference when adding the "initramfs_async=0" boot command line
> > > argument. The measurement list between boot_aggregate and boot_aggregate_late is
> > > exactly the same.
> > > 
> > 
> > That's quite interesting. This means there're some file operation
> > between late_initcall and late_initcall_sync
> > even before run_init_process() except initramfs population.
> > 
> > Since initramfs population flush all fputs() it generates and
> > boot_aggregate_late is generated before init process is loaded,
> > I honestly have no idea who triggers above file operations.
> > 
> > And it seems a little bit weird that it opens the /usr/bin/kmod
> > and its configuration from kernel not by init_process or other user
> > process...
> > 
> 
> If you don't mind, Could i get some stacktrace for one of file measurement log
> between boot_aggregate and boot_aggreate_late?
> 
> Though I try to produce like you, I've gotten failure to reproduce.
> Sorry to bother you. but it would be helpful to understand where they
> came from.

The kernel selftests caused the measurements between late_initcall and
late_initcall_sync.  After disabling all of the kernel selftests, there weren't
any measurements. Re-enabling the FIPS selftests on PowerVM LPAR resulted in
measurements.  (I didn't try re-enabling any of the other selftests.)

CONFIG_FIPS_SIGNATURE_SELFTEST=y
CONFIG_FIPS_SIGNATURE_SELFTEST_RSA=y
CONFIG_FIPS_SIGNATURE_SELFTEST_ECDSA=y

Mimi

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Yeoreum Yun]

Hi Mimi,

> On Thu, 2026-05-07 at 21:03 +0100, Yeoreum Yun wrote:
> > Hi Mimi,
> > 
> > > 
> > > > On Thu, 2026-05-07 at 06:50 +0100, Yeoreum Yun wrote:
> > > > > Hi Mimi,
> > > > > 
> > > > > > On Wed, 2026-05-06 at 14:57 +0100, Yeoreum Yun wrote:
> > > > > > > > > > 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}
> > > > > > > 
> > > > > > > Thanks. but I still wonder what meaasurements there are between
> > > > > > > boot_aggregate and boot_aggregate_late.
> > > > > > > Might be there would be key measurements if it takes more than
> > > > > > > 5 mins before generating boot_aggregate_late but this seems rare.
> > > > > > > 
> > > > > > > If you don't mind, would you share the contents of the log between
> > > > > > > boot_aggregate and boot_aggregate_late?
> > > > > > > since I only get a kernel_version in my environment.
> > > > > > 
> > > > > >      1	10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> > > > > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > > > > boot_aggregate 
> > > > > >      2	10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf
> > > > > > sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2
> > > > > > kernel_version 372e312e302d7263312b
> > > > > >      3	10 92c40bfd65512d5224cddb9fb64fef0d72e1c182 ima-sig
> > > > > > sha256:412bae0d0e85a99971d6eda198dd2fed3c2959715e8a17a4caddc7bc605bdeeb
> > > > > > /usr/bin/kmod 
> > > > > >      4	10 a18f997e1e82d0ef416f93683966d7dda875d71c ima-sig
> > > > > > sha256:0050fcc672e03cfdc3a50c771ca9f5219478e5538980a26fd4484620712d8163
> > > > > > /usr/lib64/ld64.so.2 
> > > > > >      5	10 88f343618caeeed92ed8281d627f4565b0499d66 ima-sig
> > > > > > sha256:a0e83c084d8c227f1150a8cd94eece61f62bc1da30f98d1cf57ca7db241a9c45
> > > > > > /etc/ld.so.cache 
> > > > > >      6	10 e047868f01908eb95aa180693291decab82bb6be ima-sig
> > > > > > sha256:42ebf9cc684419de4d8a1d624102716d88fbcf957f47e50a9a08e38b338023ac
> > > > > > /usr/lib64/libzstd.so.1.5.5 
> > > > > >      7	10 da069bc6a44d454510a76c69d3a54c3b238ae27e ima-sig
> > > > > > sha256:9b7c788e75c16c8827062016cf15826e43661c4b5b56813ea07ff2635bea2710
> > > > > > /usr/lib64/liblzma.so.5.6.2 
> > > > > >      8	10 7ade414e736e7b449cda5ec5e0277b99548e89c6 ima-sig
> > > > > > sha256:d899452e8e6369e436ba1a565833d6dcf0d09c35e40ffc0979cf4de2bdb8f421
> > > > > > /usr/lib64/libz.so.1.3.1.zlib-ng 
> > > > > >      9	10 9a9da8326f36237a47d6ed21bdffd0e1ff855e2a ima-sig
> > > > > > sha256:a848f396db7ad135f851b5e9aeb32f4a3ef1439c7913b9b95ab1cda69251f6ad
> > > > > > /usr/lib64/libcrypto.so.3.5.1 
> > > > > >     10	10 3201d27cd4028f02fc9088ec33e2d0ceb72d2c5b ima-sig
> > > > > > sha256:e52dcd1850555c08d60fefe56694c1179b4eaa5796db0907606552ece8e1bab1
> > > > > > /usr/lib64/libgcc_s-14-20250617.so.1 
> > > > > >     11	10 3b4c6f13e52ca060b290709f737b1ff66564226f ima-sig
> > > > > > sha256:f2a900a5b980b289dc028dd3caab16b1b0ad037f2e875546bb3197d23ff241f0
> > > > > > /usr/lib64/glibc-hwcaps/power10/libc.so.6 
> > > > > >     12	10 b23b616cbd3c9dc4c5743d121c1c5a702b461a9c ima-sig
> > > > > > sha256:5a682022beeea9ee7f36a70f0465942bf32e9675d3f45355088e148787e02175
> > > > > > /usr/lib/modprobe.d/dist-alsa.conf 
> > > > > >     13	10 aec07fad18697f295d7e06796fc8dfd3b472f9c3 ima-sig
> > > > > > sha256:067d949bab3bb085d0936031881ff73b2ab39f34b9a90cbd01396d1987ff6658
> > > > > > /usr/lib/modprobe.d/dist-blacklist.conf 
> > > > > >     14	10 c402c56b66e65914148efd6e3cf0b1d616daabe6 ima-sig
> > > > > > sha256:120a02e9b88ba74949224eca7385825e39880f5687f739ade07d94ee22ffe325
> > > > > > /etc/modprobe.d/firewalld-sysctls.conf 
> > > > > >     15	10 e358ca12bd58e1ce4845e299e1aea8b81edf86f9 ima-sig
> > > > > > sha256:fa27abcd357a16ee1254ba38d1225b7f0724036c07ce3d0e83b29eb72d97c419
> > > > > > /etc/modprobe.d/l2tp_eth-blacklist.conf 
> > > > > >     16	10 4b036d41435d7df3a72b38880f5fe231904b7b66 ima-sig
> > > > > > sha256:ecf5f948bfbfb726879a910b3174d139c8af6b1745c88dcc1e4a1cf532c02299
> > > > > > /etc/modprobe.d/l2tp_ip-blacklist.conf 
> > > > > >     17	10 9c53a7a48c1b5218417c4f25c4a34c09a9f39830 ima-sig
> > > > > > sha256:f76c4ac232d5e96c57961a9f10194703b4df6d119530046f0b23eee70bfcb089
> > > > > > /etc/modprobe.d/l2tp_ip6-blacklist.conf 
> > > > > >     18	10 6c41d7b7d251c400b7e0ba76f7b386a746e8f4ec ima-sig
> > > > > > sha256:5cbc958f893a599ef19437014696dd7b112cf9af6a4348830177f8a8f78aa1b3
> > > > > > /etc/modprobe.d/l2tp_netlink-blacklist.conf 
> > > > > >     19	10 f37ef48faef5bc51e29d47531726af0bd0654655 ima-sig
> > > > > > sha256:7a3d63acb49e4a69b482f26624761b5778fbd6b77be8a3f36926b379b5f965ed
> > > > > > /etc/modprobe.d/l2tp_ppp-blacklist.conf 
> > > > > >     20	10 82ef59779acdfd6e9b35521bfa09e6ba86fd6174 ima-sig
> > > > > > sha256:6a8f2009d87deba7a2de46e3d0c46b114fe388d188b00b9a382fc2156aabb676
> > > > > > /usr/lib/modules/7.1.0-rc1+/modules.softdep 
> > > > > >     21	10 6ae994e33a6313ab4535da90f5cb6c3beaec7b86 ima-sig
> > > > > > sha256:268695dbf23bd0170ec9a95b10e8d596205fd7436617d10101907171bf004b7c
> > > > > > /etc/modprobe.d/sctp-blacklist.conf 
> > > > > >     22	10 b2c238ae66b03f56191d9955a5ad0f3110bb7e2b ima-sig
> > > > > > sha256:64a8ebb0a1fd712a9aeb7aa0f0ad0b72d3277034c8bfa3b66ab063e201d6527e
> > > > > > /etc/modprobe.d/sctp_diag-blacklist.conf 
> > > > > >     23	10 c0443f2d3c078959ae86276df23abe172234a55d ima-sig
> > > > > > sha256:e5a3958cbd3684b63f3cada6604469cc56f727b106d5524daf5aefa6935a48ce
> > > > > > /usr/lib/modprobe.d/systemd.conf 
> > > > > >     24	10 5c46e012bc7fffc3256b166282a7eaa4bea5fa33 ima-sig
> > > > > > sha256:6560abcdd2cdb41e1d0fe73052298d612920d5bccb4a3a7c82bc73895128e760
> > > > > > /etc/modprobe.d/tipc_diag-blacklist.conf 
> > > > > >     25	10 d5fb1836364732fbc4f87aa7d2c984cf30bdbfd3 ima-sig
> > > > > > sha256:358703c09ac2d2c653e11bbc7c65d378c8496e87ca47307f86c36b0b29640598
> > > > > > /etc/modprobe.d/tuned.conf 
> > > > > >     26	10 a85107163729f696f316d46c0bf3f65f713ba972 ima-sig
> > > > > > sha256:7410bb4cec56892e8b0010c5c8b72be532784ccf0240aa0677c5be085a530f65
> > > > > > /usr/lib/modules/7.1.0-rc1+/modules.dep.bin 
> > > > > >     27	10 80eb261ffb2cc3528d90c33b1c624f657a045867 ima-sig
> > > > > > sha256:856e0f083226f8b4fb7d1d71447fb841dae18ea9a50ea6d8505a206167288e1d
> > > > > > /usr/lib/modules/7.1.0-rc1+/modules.alias.bin 
> > > > > >     28	10 6af2d661da470d7a1c9909ddbc074d3d265eb1d7 ima-sig
> > > > > > sha256:4853ca200598c52970c380fda99484068e7db4961a4f94faac6abcfbbd52d150
> > > > > > /usr/lib/modules/7.1.0-rc1+/modules.symbols.bin 
> > > > > >     29	10 6f9cd405bd57d925baae6ae66c273c61c90b3bc8 ima-sig
> > > > > > sha256:193d1e1004848f7d391877507b69a7953e1f94ddbe70eb0e2cf6dc45fce7cd6a
> > > > > > /usr/lib/modules/7.1.0-rc1+/modules.builtin.alias.bin 
> > > > > >     30	10 4e20b980bf3a825a866be0c46033ed654df4aeba ima-sig
> > > > > > sha256:3a0e3c56d51ba98258ff13f93f82c837de22f4b707d24678f82893babf4d77ea
> > > > > > /usr/lib/modules/7.1.0-rc1+/modules.builtin.bin 
> > > > > >     31	10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> > > > > > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > > > > > boot_aggregate_late 
> > > > > >     32	10 81830cd3d799e006698258dc1b11fe29a56eeef5 ima-sig
> > > > > > sha256:d1651dc50bb5b92c1badcab9aa4dbbca40cb704cdc707d1c536b41d7b1aa465e
> > > > > > /usr/lib/systemd/systemd 
> > > > > 
> > > > > Hmm... Theses measurements seems to happen while populating
> > > > > initramfs which triggers file_post_open as async
> > > > > (and I see the RAMFS seems not part of DONT_MEASURE in IMA).
> > > > > 
> > > > > If you don't mind, Could you check whether this measurements still
> > > > > happen with initramfs_async=0?
> > > > > 
> > > > > If this measurements aren't generated with above option,
> > > > > there is a question whether let IMA measure initramfs which can be
> > > > > measured or not depending on boot option or timing (some file measurements
> > > > > could be lost all when do_populate_rootfs() executes concurrently while
> > > > > running late_initcall).
> > > > 
> > > > There's no difference when adding the "initramfs_async=0" boot command line
> > > > argument. The measurement list between boot_aggregate and boot_aggregate_late is
> > > > exactly the same.
> > > > 
> > > 
> > > That's quite interesting. This means there're some file operation
> > > between late_initcall and late_initcall_sync
> > > even before run_init_process() except initramfs population.
> > > 
> > > Since initramfs population flush all fputs() it generates and
> > > boot_aggregate_late is generated before init process is loaded,
> > > I honestly have no idea who triggers above file operations.
> > > 
> > > And it seems a little bit weird that it opens the /usr/bin/kmod
> > > and its configuration from kernel not by init_process or other user
> > > process...
> > > 
> > 
> > If you don't mind, Could i get some stacktrace for one of file measurement log
> > between boot_aggregate and boot_aggreate_late?
> > 
> > Though I try to produce like you, I've gotten failure to reproduce.
> > Sorry to bother you. but it would be helpful to understand where they
> > came from.
> 
> The kernel selftests caused the measurements between late_initcall and
> late_initcall_sync.  After disabling all of the kernel selftests, there weren't
> any measurements. Re-enabling the FIPS selftests on PowerVM LPAR resulted in
> measurements.  (I didn't try re-enabling any of the other selftests.)
> 
> CONFIG_FIPS_SIGNATURE_SELFTEST=y
> CONFIG_FIPS_SIGNATURE_SELFTEST_RSA=y
> CONFIG_FIPS_SIGNATURE_SELFTEST_ECDSA=y

Thanks for shraring this ;)

I found the reason for those mesaurements. Those come from the
request_module() and usermode-thread generates them while handling module
loading request for crypto-x962(ecdsa-nist-p256).
Since it's not a real kernel module,
I confirmed file measurements between late_initcall and
late_initcall_sync are gone for modeprobe with below change:

@@ -1246,9 +1250,14 @@ EXPORT_SYMBOL_GPL(ima_measure_critical_data);
  */
 static int ima_kernel_module_request(char *kmod_name)
 {
        if (strncmp(kmod_name, "crypto-pkcs1(rsa,", 17) == 0)
                return -EINVAL;

+       if (IS_BUILTIN(CONFIG_CRYPTO_ECDSA) &&
+           (strncmp(kmod_name, "crypto-x962(ecdsa", 17) == 0))
+               return -EINVAL;
+
        return 0;
 }

 Though this is the only request_module() call between
 late_initcall and late_initcall_sync, but I also confirmed there're
 request_modules() call before ima initalisation before "late_initcall":

/*
 * NOTE: kmod_name is printed on ima_kernel_module_request()
 */

// This is called from module_init(stm_core_init) -> device_initcall()
// which is in driver/hwtracing/stm/core.c (built-in)
[    1.421986] ima: kmod_name: stm_p_basic
...
[    1.444900] ima: kmod_name: crypto-pkcs1(rsa,sha512)
[    1.444903] ima: kmod_name: crypto-pkcs1(rsa,sha512)-all
...
[    1.452029] ima: kmod_name: crypto-cbc(aes)
[    1.465321] ima: kmod_name: crypto-cbc(aes)-all
...
[    1.467845] Key type encrypted registered
[    1.467848] AppArmor: AppArmor sha256 policy hashing enabled

 // IMA is initailised at late_initcall level.
[    1.467850] ima: [init_ima_late:1336]

If IMA should care request_module() from kernel before IMA init,
I think there is no way to solve except queuing those events
(kernel_load_data/kernel_load_post_data and open for module binary etc.)
though it breaks "measure before use" principle since IMA couldn't
measure at that time.

But if you don't care about those things -- some events happend before
IMA init, I think your suggestion -- controlling the init time of ima_init()
via a Kconfig option is good and ignoring some usermodehelper request
including request_module() before IMA initialisation upto user by that option.

-- 
Sincerely,
Yeoreum Yun

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Mimi Zohar]

On Fri, 2026-05-08 at 10:06 +0100, Yeoreum Yun wrote:

> > The kernel selftests caused the measurements between late_initcall and
> > late_initcall_sync.  After disabling all of the kernel selftests, there weren't
> > any measurements. Re-enabling the FIPS selftests on PowerVM LPAR resulted in
> > measurements.  (I didn't try re-enabling any of the other selftests.)
> > 
> > CONFIG_FIPS_SIGNATURE_SELFTEST=y
> > CONFIG_FIPS_SIGNATURE_SELFTEST_RSA=y
> > CONFIG_FIPS_SIGNATURE_SELFTEST_ECDSA=y
> 
> Thanks for shraring this ;)
> 
> I found the reason for those mesaurements. Those come from the
> request_module() and usermode-thread generates them while handling module
> loading request for crypto-x962(ecdsa-nist-p256).
> Since it's not a real kernel module,
> I confirmed file measurements between late_initcall and
> late_initcall_sync are gone for modeprobe with below change:
> 
> @@ -1246,9 +1250,14 @@ EXPORT_SYMBOL_GPL(ima_measure_critical_data);
>   */
>  static int ima_kernel_module_request(char *kmod_name)
>  {
>         if (strncmp(kmod_name, "crypto-pkcs1(rsa,", 17) == 0)
>                 return -EINVAL;
> 
> +       if (IS_BUILTIN(CONFIG_CRYPTO_ECDSA) &&
> +           (strncmp(kmod_name, "crypto-x962(ecdsa", 17) == 0))
> +               return -EINVAL;
> +
>         return 0;
>  }
> 
>  Though this is the only request_module() call between
>  late_initcall and late_initcall_sync, but I also confirmed there're
>  request_modules() call before ima initalisation before "late_initcall":
> 
> /*
>  * NOTE: kmod_name is printed on ima_kernel_module_request()
>  */
> 
> // This is called from module_init(stm_core_init) -> device_initcall()
> // which is in driver/hwtracing/stm/core.c (built-in)
> [    1.421986] ima: kmod_name: stm_p_basic
> ...
> [    1.444900] ima: kmod_name: crypto-pkcs1(rsa,sha512)
> [    1.444903] ima: kmod_name: crypto-pkcs1(rsa,sha512)-all
> ...
> [    1.452029] ima: kmod_name: crypto-cbc(aes)
> [    1.465321] ima: kmod_name: crypto-cbc(aes)-all
> ...
> [    1.467845] Key type encrypted registered
> [    1.467848] AppArmor: AppArmor sha256 policy hashing enabled
> 
>  // IMA is initailised at late_initcall level.
> [    1.467850] ima: [init_ima_late:1336]
> 
> If IMA should care request_module() from kernel before IMA init,
> I think there is no way to solve except queuing those events
> (kernel_load_data/kernel_load_post_data and open for module binary etc.)
> though it breaks "measure before use" principle since IMA couldn't
> measure at that time.
> 
> But if you don't care about those things -- some events happend before
> IMA init, I think your suggestion -- controlling the init time of ima_init()
> via a Kconfig option is good and ignoring some usermodehelper request
> including request_module() before IMA initialisation upto user by that option.

Thank you for the complete analysis.  The early measurements before the TPM is
initialized is a problem that needs to be addressed.  As to whether the solution
will require queueing is yet to be determined. (Roberto has some thoughts on
addressing it.) This discussion makes it clear that simply delaying IMA
initialization by moving it from late_initcall to late_initcall_sync could miss
measurements.  That said, exposing it as an opt-in Kconfig for those who accept
the risk is a sensible pragmatic compromise.

Mimi

Re: [PATCH] ima: debugging late_initcall_sync measurements

[Yeoreum Yun]

> On Fri, 2026-05-08 at 10:06 +0100, Yeoreum Yun wrote:
> 
> > > The kernel selftests caused the measurements between late_initcall and
> > > late_initcall_sync.  After disabling all of the kernel selftests, there weren't
> > > any measurements. Re-enabling the FIPS selftests on PowerVM LPAR resulted in
> > > measurements.  (I didn't try re-enabling any of the other selftests.)
> > > 
> > > CONFIG_FIPS_SIGNATURE_SELFTEST=y
> > > CONFIG_FIPS_SIGNATURE_SELFTEST_RSA=y
> > > CONFIG_FIPS_SIGNATURE_SELFTEST_ECDSA=y
> > 
> > Thanks for shraring this ;)
> > 
> > I found the reason for those mesaurements. Those come from the
> > request_module() and usermode-thread generates them while handling module
> > loading request for crypto-x962(ecdsa-nist-p256).
> > Since it's not a real kernel module,
> > I confirmed file measurements between late_initcall and
> > late_initcall_sync are gone for modeprobe with below change:
> > 
> > @@ -1246,9 +1250,14 @@ EXPORT_SYMBOL_GPL(ima_measure_critical_data);
> >   */
> >  static int ima_kernel_module_request(char *kmod_name)
> >  {
> >         if (strncmp(kmod_name, "crypto-pkcs1(rsa,", 17) == 0)
> >                 return -EINVAL;
> > 
> > +       if (IS_BUILTIN(CONFIG_CRYPTO_ECDSA) &&
> > +           (strncmp(kmod_name, "crypto-x962(ecdsa", 17) == 0))
> > +               return -EINVAL;
> > +
> >         return 0;
> >  }
> > 
> >  Though this is the only request_module() call between
> >  late_initcall and late_initcall_sync, but I also confirmed there're
> >  request_modules() call before ima initalisation before "late_initcall":
> > 
> > /*
> >  * NOTE: kmod_name is printed on ima_kernel_module_request()
> >  */
> > 
> > // This is called from module_init(stm_core_init) -> device_initcall()
> > // which is in driver/hwtracing/stm/core.c (built-in)
> > [    1.421986] ima: kmod_name: stm_p_basic
> > ...
> > [    1.444900] ima: kmod_name: crypto-pkcs1(rsa,sha512)
> > [    1.444903] ima: kmod_name: crypto-pkcs1(rsa,sha512)-all
> > ...
> > [    1.452029] ima: kmod_name: crypto-cbc(aes)
> > [    1.465321] ima: kmod_name: crypto-cbc(aes)-all
> > ...
> > [    1.467845] Key type encrypted registered
> > [    1.467848] AppArmor: AppArmor sha256 policy hashing enabled
> > 
> >  // IMA is initailised at late_initcall level.
> > [    1.467850] ima: [init_ima_late:1336]
> > 
> > If IMA should care request_module() from kernel before IMA init,
> > I think there is no way to solve except queuing those events
> > (kernel_load_data/kernel_load_post_data and open for module binary etc.)
> > though it breaks "measure before use" principle since IMA couldn't
> > measure at that time.
> > 
> > But if you don't care about those things -- some events happend before
> > IMA init, I think your suggestion -- controlling the init time of ima_init()
> > via a Kconfig option is good and ignoring some usermodehelper request
> > including request_module() before IMA initialisation upto user by that option.
> 
> Thank you for the complete analysis.  The early measurements before the TPM is
> initialized is a problem that needs to be addressed.  As to whether the solution
> will require queueing is yet to be determined. (Roberto has some thoughts on
> addressing it.) This discussion makes it clear that simply delaying IMA
> initialization by moving it from late_initcall to late_initcall_sync could miss
> measurements.  That said, exposing it as an opt-in Kconfig for those who accept
> the risk is a sensible pragmatic compromise.

I think once we address ealry measurements before intialising TPM,
It doesn't matter when IMA is initialissed since they're considered as
ealry measurements anyway.

BTW, I'm not sure whether we should take pragmatic compromise first to
support deferred TPM initialisation or solving it together via solution
of ealry measurements (whatever it is) in now.

-- 
Sincerely,
Yeoreum Yun

Re: [RFC PATCH v3 4/4] Revert "firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"

[Sudeep Holla]

On Fri, Apr 24, 2026 at 02:24:42PM +0100, Jonathan McDowell wrote:
> From: Yeoreum Yun <yeoreum.yun@arm.com>
> 
> This reverts commit 0e0546eabcd6c19765a8dbf5b5db3723e7b0ea75, which was
> added to address ordering issues with the IMA LSM initialisation where
> the TPM would not be fully ready by the time IMA wanted it. This has
> been resolved within IMA by retrying setup during late_initcall_sync if
> the TPM is not available at first.
> 

I have made this part of [1] and intend to take it via arm-soc. I don't
see a strict dependency on 3/4 here and one can test the -next integration
branch. I don't believe IMA/TPM is in arm64 defconfig, so anyone testing
must be aware of all the details.

Please shout if you disagree. TPM revert can go independently IMO.

-- 
Regards,
Sudeep

[1] https://lore.kernel.org/all/20260508-b4-ffa_plat_dev-v1-0-c5a30f8cf7b8@kernel.org/