* Re: [PATCH] tpm: svsm: constify tpm_chip_ops
From: Stefano Garzarella @ 2026-05-06 7:20 UTC (permalink / raw)
To: David Windsor
Cc: Peter Huewe, Jarkko Sakkinen, Jason Gunthorpe, linux-integrity,
linux-kernel
In-Reply-To: <20260505202738.145800-1-dwindsor@gmail.com>
On Tue, May 05, 2026 at 04:27:38PM -0400, David Windsor wrote:
>Constify the SVSM vTPM ops. It is statically initialized and never
>written to, so let's store it in .rodata.
>
>Every other tpm_class_ops instance in drivers/char/tpm/ is already
>const.
>
>Signed-off-by: David Windsor <dwindsor@gmail.com>
>---
> drivers/char/tpm/tpm_svsm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
LGTM!
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Yeoreum Yun @ 2026-05-06 7:23 UTC (permalink / raw)
To: Mimi Zohar
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <afrXmRiq7XvSe6yN@e129823.arm.com>
> > On Sun, 2026-05-03 at 07:36 -0400, Mimi Zohar wrote:
> > > On Fri, 2026-05-01 at 12:52 -0400, David Safford wrote:
> > > > On Thu, Apr 30, 2026 at 5:43 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > >
> > > > > On Thu, 2026-04-30 at 10:48 +0100, Yeoreum Yun wrote:
> > > > > > With above change I confirmed there is no meaurement log
> > > > > > between boot_aggregate and boot_aggregate_late except "kernel_version"
> > > > > > But this is ignorable since this UTS measurement is done in
> > > > > > "ima_init_core() (old: ima_init())" and it is part of ima initialisation.
> > > > > >
> > > > > > 1. ima_policy=tcb
> > > > > >
> > > > > > # cat /sys/kernel/security/ima/ascii_runtime_measurements
> > > > > > 10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
> > > > > > 10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
> > > > > > 10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox
> > > > snip
> > > > > >
> > > > > > 2. ima_policy=critical_data
> > > > > >
> > > > > > # cat /sys/kernel/security/ima/ascii_runtime_measurements
> > > > > > 10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
> > > > > > 10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
> > > > > > 10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
> > > > > >
> > > > > > Therefore, init_ima() could move into late_initcall_sync like v1 did:
> > > > > > - https://lore.kernel.org/all/20260417175759.3191279-2-yeoreum.yun@arm.com/
> > > > >
> > > > > Thanks, Yeoreum. It's a bit premature to claim it's "safe" to move the
> > > > > initcall. Hopefully others will respond.
> > > > >
> > > > > Mimi
> > > >
> > > > I have also run with this patch on a number of bare metal and virtual machines,
> > > > running everything from default Fedora 44 to a version with everything turned on
> > > > (uefi secure boot, UKI with sdboot stub measurements, IMA measurement
> > > > and appraisal enabled,
> > > > all systemd measurements on, and systemd using the TPM for root
> > > > partition decryption.)
> > > > I too see only the kernel_version event between the normal and late
> > > > calls, if ima_policy=critical_data.
> > >
> > > Thanks, Dave! Were all the systems you tested x86_64? The next step would be
> > > to test on different arch's (e.g. Z, Power).
> >
> > On both Z and PowerVM, there are ~30 measurements between boot_aggregate and
> > boot_aggregate_late. For example, on PowerVM:
> >
> > # grep -n boot_aggregate
> > /sys/kernel/security/integrity/ima/ascii_runtime_measurements
> >
> > 1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > boot_aggregate
> > 31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> > sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> > boot_aggregate_late
> >
> > It would be interesting to the results from a Raspberry Pi 5 as well,
> > with/without a TPM.
>
> Honestly, I find this result hard to accept.
>
> This effectively means that there is code invoking IMA measurement during late_initcall().
> It also implies that if, in the future, a late_initcall is added that performs
> an IMA measurement before IMA initialization has occurred accoding to order by linker,
> that measurement could be missed.
>
> Could you please check how the index (1, 31) was added to either
> ima_template_entry or ima_queue_entry to produce this result?
And since most IMA measurements occur during module, file, or bprm operations,
I’m really curious about where such operations take place
before the init process is loaded, since init is started only after all
initcalls have completed.
Personally, I find it hard to believe that this kind of critical data
measurement comes from dm or SELinux, as those typically operate via
ioctl or load policies after userspace becomes available.
If you don’t mind, could you share your test code for the index,
as well as some stack traces? That would help me understand
where these measurements are coming from.
Thanks!
>
> --
> Sincerely,
> Yeoreum Yun
>
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Sudeep Holla @ 2026-05-06 7:27 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
Sudeep Holla, linux-arm-kernel, kvmarm, jarkko, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris,
serge, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <afohuFhVBIyUFEMT@e129823.arm.com>
On Tue, May 05, 2026 at 05:58:32PM +0100, Yeoreum Yun wrote:
> Hi Sudeep,
>
> > On Tue, May 05, 2026 at 04:06:51PM +0100, Yeoreum Yun wrote:
> > > Hi Sudeep,
> > >
> > > > On Tue, May 05, 2026 at 10:54:08AM +0100, Yeoreum Yun wrote:
> > > > > When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> > > > > Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> > > > > buffer information, leading to failures in FF-A calls.
> > > > >
> > > > > Currently, pKVM initialisation completes at device_initcall_sync,
> > > > > while ffa_init() runs at the device_initcall level.
> > > > >
> > > > > So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> > > > > still be trapped even before finalise_pkvm() is invoked.
> > > > > As a result, this issue has not been observed.
> > > > >
> > > > > However, relying on above stuff is fragile.
> > > > > Therefore, when pKVM is enabled, the FF-A infrastructure should be
> > > > > initialised only after pKVM initialisation has been fully finalised.
> > > > >
> > > > > To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> > > > > a corresponding driver to defer initialisation of the FF-A infrastructure
> > > > > until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> > > > > when pKVM is enabled.
> > > > >
> > > >
> > > > I don't like this whole ffa root device design.
> > > > Two question for now:
> > > > 1. Can FF-A be a module on systems with pKVM which removes the need for all
> > > > this dance done here ?
> > >
> > > But this means we reduce the other feature e.x) IMA with TPM over
> > > FF-A and pKVM feature. Since IMA must be a built-in, we couldn't avoid
> > > to build FF-A driver with built-in.
> > >
> > > > 2. If it is a requirement to have this built-in, I prefer to add a probe
> > > > and defer it instead of this root ffa device.
> > >
> > > But, How? anyway all of FF-A device & driver couldn't be probed unless
> > > FF-A initialisation is finished and How can we trigger FF-A initailise
> > > after pKVM finish its initialisation?
> > >
> > > The problem is ff-a intiailisation happens before pKVM finish its
> > > initailasation and to do defer probe, it should use dd-model and
> > > As we discussed in other thread, notifier couldn't be a soluation.
> > >
> > > Could you let me share other way I'm missing?
> > >
> >
> > Will something like below work ?
>
> It might work and when I write the code I thougt about whether to
> use add platform device but I didn't find why this is better than
> to create root device of FF-A (anyway creating a simple platform device
> for FF-A seems similar to create root device)
First, you tried to force the FF-A core to be treated as an FF-A device, then
added several bus-code changes to handle it as a "special root" device while
skipping all FF-A device functionality. Please consider the purpose of
creating it as an FF-A device if additional code is then required to bypass
the functionality it provides.
> If you don't mind why it would be better than to create FF-A root
> device in FF-A bus?
>
> > If we add DT bindings, then we can add
> > of_match_table and drop the platform device creation. Also we can adjust
> > the parent device the way you have done by a simple change(not done in
> > this untested/not compiled change).
>
> Might for a DT, but do we need to platform device creation for ACPI case
> anyway?
>
>
Just acpi_match_table instead of of_match_table.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Sudeep Holla @ 2026-05-06 7:46 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
linux-arm-kernel, kvmarm, Sudeep Holla, jarkko, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris,
serge, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <20260505-adaptable-mussel-of-virtuosity-2751db@sudeepholla>
On Tue, May 05, 2026 at 05:32:15PM +0100, Sudeep Holla wrote:
> On Tue, May 05, 2026 at 04:06:51PM +0100, Yeoreum Yun wrote:
> > Hi Sudeep,
> >
> > > On Tue, May 05, 2026 at 10:54:08AM +0100, Yeoreum Yun wrote:
> > > > When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> > > > Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> > > > buffer information, leading to failures in FF-A calls.
> > > >
> > > > Currently, pKVM initialisation completes at device_initcall_sync,
> > > > while ffa_init() runs at the device_initcall level.
> > > >
> > > > So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> > > > still be trapped even before finalise_pkvm() is invoked.
> > > > As a result, this issue has not been observed.
> > > >
> > > > However, relying on above stuff is fragile.
> > > > Therefore, when pKVM is enabled, the FF-A infrastructure should be
> > > > initialised only after pKVM initialisation has been fully finalised.
> > > >
> > > > To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> > > > a corresponding driver to defer initialisation of the FF-A infrastructure
> > > > until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> > > > when pKVM is enabled.
> > > >
> > >
> > > I don't like this whole ffa root device design.
> > > Two question for now:
> > > 1. Can FF-A be a module on systems with pKVM which removes the need for all
> > > this dance done here ?
> >
> > But this means we reduce the other feature e.x) IMA with TPM over
> > FF-A and pKVM feature. Since IMA must be a built-in, we couldn't avoid
> > to build FF-A driver with built-in.
> >
> > > 2. If it is a requirement to have this built-in, I prefer to add a probe
> > > and defer it instead of this root ffa device.
> >
> > But, How? anyway all of FF-A device & driver couldn't be probed unless
> > FF-A initialisation is finished and How can we trigger FF-A initailise
> > after pKVM finish its initialisation?
> >
> > The problem is ff-a intiailisation happens before pKVM finish its
> > initailasation and to do defer probe, it should use dd-model and
> > As we discussed in other thread, notifier couldn't be a soluation.
> >
> > Could you let me share other way I'm missing?
> >
>
> Will something like below work ? If we add DT bindings, then we can add
> of_match_table and drop the platform device creation. Also we can adjust
> the parent device the way you have done by a simple change(not done in
> this untested/not compiled change).
>
I have pushed the changes[1], will post once tested and you confirm your
use-case also works.
--
Regards,
Sudeep
[1] https://git.kernel.org/sudeep.holla/l/ffa_plat_dev
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Yeoreum Yun @ 2026-05-06 7:49 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
linux-arm-kernel, kvmarm, jarkko, zohar, roberto.sassu,
dmitry.kasatkin, eric.snowberg, paul, jmorris, serge, maz, oupton,
joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas, will
In-Reply-To: <20260506-warm-deer-of-energy-522bfa@sudeepholla>
Hi,
> On Tue, May 05, 2026 at 05:58:32PM +0100, Yeoreum Yun wrote:
> > Hi Sudeep,
> >
> > > On Tue, May 05, 2026 at 04:06:51PM +0100, Yeoreum Yun wrote:
> > > > Hi Sudeep,
> > > >
> > > > > On Tue, May 05, 2026 at 10:54:08AM +0100, Yeoreum Yun wrote:
> > > > > > When pKVM is enabled, the FF-A driver must be initialised after pKVM.
> > > > > > Otherwise, pKVM cannot negotiate the FF-A version or obtain the RX/TX
> > > > > > buffer information, leading to failures in FF-A calls.
> > > > > >
> > > > > > Currently, pKVM initialisation completes at device_initcall_sync,
> > > > > > while ffa_init() runs at the device_initcall level.
> > > > > >
> > > > > > So far, linker deployes kvm_arm_init() before ffa_init(), and SMCs can
> > > > > > still be trapped even before finalise_pkvm() is invoked.
> > > > > > As a result, this issue has not been observed.
> > > > > >
> > > > > > However, relying on above stuff is fragile.
> > > > > > Therefore, when pKVM is enabled, the FF-A infrastructure should be
> > > > > > initialised only after pKVM initialisation has been fully finalised.
> > > > > >
> > > > > > To achieve this, introduce an ffa_root_dev ("arm-ffa") and
> > > > > > a corresponding driver to defer initialisation of the FF-A infrastructure
> > > > > > until pKVM initialisation is complete, and to defer probing of all FF-A devices until then
> > > > > > when pKVM is enabled.
> > > > > >
> > > > >
> > > > > I don't like this whole ffa root device design.
> > > > > Two question for now:
> > > > > 1. Can FF-A be a module on systems with pKVM which removes the need for all
> > > > > this dance done here ?
> > > >
> > > > But this means we reduce the other feature e.x) IMA with TPM over
> > > > FF-A and pKVM feature. Since IMA must be a built-in, we couldn't avoid
> > > > to build FF-A driver with built-in.
> > > >
> > > > > 2. If it is a requirement to have this built-in, I prefer to add a probe
> > > > > and defer it instead of this root ffa device.
> > > >
> > > > But, How? anyway all of FF-A device & driver couldn't be probed unless
> > > > FF-A initialisation is finished and How can we trigger FF-A initailise
> > > > after pKVM finish its initialisation?
> > > >
> > > > The problem is ff-a intiailisation happens before pKVM finish its
> > > > initailasation and to do defer probe, it should use dd-model and
> > > > As we discussed in other thread, notifier couldn't be a soluation.
> > > >
> > > > Could you let me share other way I'm missing?
> > > >
> > >
> > > Will something like below work ?
> >
> > It might work and when I write the code I thougt about whether to
> > use add platform device but I didn't find why this is better than
> > to create root device of FF-A (anyway creating a simple platform device
> > for FF-A seems similar to create root device)
>
> First, you tried to force the FF-A core to be treated as an FF-A device, then
> added several bus-code changes to handle it as a "special root" device while
> skipping all FF-A device functionality. Please consider the purpose of
> creating it as an FF-A device if additional code is then required to bypass
> the functionality it provides.
Okay. I'll do with platform device then.
>
> > If you don't mind why it would be better than to create FF-A root
> > device in FF-A bus?
> >
> > > If we add DT bindings, then we can add
> > > of_match_table and drop the platform device creation. Also we can adjust
> > > the parent device the way you have done by a simple change(not done in
> > > this untested/not compiled change).
> >
> > Might for a DT, but do we need to platform device creation for ACPI case
> > anyway?
> >
> >
>
> Just acpi_match_table instead of of_match_table.
I mean like DT node, it seems to add some "FF-A" device for this.
Anyway, right now as your suggestion, let me respin with platform device
again.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [RFC PATCH 1/3] arm64: KVM: defer kvm_init() to finalise_pkvm() when pKVM is enabled
From: Sudeep Holla @ 2026-05-06 7:50 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
Sudeep Holla, linux-arm-kernel, kvmarm, jarkko, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris,
serge, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <20260505095409.1948371-2-yeoreum.yun@arm.com>
On Tue, May 05, 2026 at 10:54:07AM +0100, Yeoreum Yun wrote:
> This patch is a preparatory change to address dependency issues
> between the FF-A driver and pKVM.
>
> kvm_init() should be invoked from finalise_pkvm(),
> as this is the point where pKVM initialisation is finalised and
> the system transitions into the protected mode.
>
> Deferring kvm_init() ensures that KVM is initialised only after pKVM has
> fully established its protected environment.
>
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> ---
> arch/arm64/kvm/arm.c | 8 +++++---
> arch/arm64/kvm/pkvm.c | 15 ++++++++++++++-
> 2 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 8bb2c7422cc8..663b1d447a9b 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -3025,9 +3025,11 @@ static __init int kvm_arm_init(void)
> * FIXME: Do something reasonable if kvm_init() fails after pKVM
> * hypervisor protection is finalized.
> */
> - err = kvm_init(sizeof(struct kvm_vcpu), 0, THIS_MODULE);
> - if (err)
> - goto out_subs;
> + if (!is_protected_kvm_enabled()) {
> + err = kvm_init(sizeof(struct kvm_vcpu), 0, THIS_MODULE);
> + if (err)
> + goto out_subs;
> + }
>
> /*
> * This should be called after initialization is done and failure isn't
> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> index 053e4f733e4b..48b06d384570 100644
> --- a/arch/arm64/kvm/pkvm.c
> +++ b/arch/arm64/kvm/pkvm.c
> @@ -17,6 +17,7 @@
> #include "hyp_constants.h"
>
> DEFINE_STATIC_KEY_FALSE(kvm_protected_mode_initialized);
> +EXPORT_SYMBOL_GPL(kvm_protected_mode_initialized);
>
I am not sure if this is needed when FF-A is built as module. If others
are OK with it, I am fine. But I am thinking if we need to use this in
FF-A driver which can be built-in or a module, we can add
IS_BUILTIN(CONFIG_ARM_FFA_*)
--
Regards,
Sudeep
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Sudeep Holla @ 2026-05-06 8:14 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
Sudeep Holla, linux-arm-kernel, kvmarm, jarkko, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris,
serge, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <afrygFx4OoCbbr+a@e129823.arm.com>
On Wed, May 06, 2026 at 08:49:20AM +0100, Yeoreum Yun wrote:
> Hi,
>
> I mean like DT node, it seems to add some "FF-A" device for this.
> Anyway, right now as your suggestion, let me respin with platform device
> again.
>
Please check my branch ffa_plat_dev [1] as I noted in the last email.
--
Regards,
Sudeep
[1] https://git.kernel.org/sudeep.holla/l/ffa_plat_dev
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Yeoreum Yun @ 2026-05-06 8:58 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
linux-arm-kernel, kvmarm, jarkko, zohar, roberto.sassu,
dmitry.kasatkin, eric.snowberg, paul, jmorris, serge, maz, oupton,
joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas, will
In-Reply-To: <20260506-colossal-bee-of-discussion-08ac76@sudeepholla>
> On Wed, May 06, 2026 at 08:49:20AM +0100, Yeoreum Yun wrote:
> > Hi,
> >
> > I mean like DT node, it seems to add some "FF-A" device for this.
> > Anyway, right now as your suggestion, let me respin with platform device
> > again.
> >
>
> Please check my branch ffa_plat_dev [1] as I noted in the last email.
>
> --
> Regards,
> Sudeep
>
> [1] https://git.kernel.org/sudeep.holla/l/ffa_plat_dev
Sorry, I've seen this email after I sent former mail.
And since platform_driver_probe() prevents deferred probe.
I think it need to change jsut platform_driver_register()
for ffa_driver.
Thanks!
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Yeoreum Yun @ 2026-05-06 9:11 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
linux-arm-kernel, kvmarm, jarkko, zohar, roberto.sassu,
dmitry.kasatkin, eric.snowberg, paul, jmorris, serge, maz, oupton,
joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas, will
In-Reply-To: <afsCs56KfpoMhPH9@e129823.arm.com>
On Wed, May 06, 2026 at 09:58:27AM +0100, Yeoreum Yun wrote:
> > On Wed, May 06, 2026 at 08:49:20AM +0100, Yeoreum Yun wrote:
> > > Hi,
> > >
> > > I mean like DT node, it seems to add some "FF-A" device for this.
> > > Anyway, right now as your suggestion, let me respin with platform device
> > > again.
> > >
> >
> > Please check my branch ffa_plat_dev [1] as I noted in the last email.
> >
> > --
> > Regards,
> > Sudeep
> >
> > [1] https://git.kernel.org/sudeep.holla/l/ffa_plat_dev
>
> Sorry, I've seen this email after I sent former mail.
>
> And since platform_driver_probe() prevents deferred probe.
> I think it need to change jsut platform_driver_register()
> for ffa_driver.
>
> Thanks!
With above change, everything is good.
Thanks again!
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Sudeep Holla @ 2026-05-06 9:58 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-integrity, keyrings, linux-security-module, linux-kernel,
Sudeep Holla, linux-arm-kernel, kvmarm, jarkko, zohar,
roberto.sassu, dmitry.kasatkin, eric.snowberg, paul, jmorris,
serge, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will
In-Reply-To: <afsCs56KfpoMhPH9@e129823.arm.com>
On Wed, May 06, 2026 at 09:58:27AM +0100, Yeoreum Yun wrote:
> > On Wed, May 06, 2026 at 08:49:20AM +0100, Yeoreum Yun wrote:
> > > Hi,
> > >
> > > I mean like DT node, it seems to add some "FF-A" device for this.
> > > Anyway, right now as your suggestion, let me respin with platform device
> > > again.
> > >
> >
> > Please check my branch ffa_plat_dev [1] as I noted in the last email.
> >
> > --
> > Regards,
> > Sudeep
> >
> > [1] https://git.kernel.org/sudeep.holla/l/ffa_plat_dev
>
> Sorry, I've seen this email after I sent former mail.
>
> And since platform_driver_probe() prevents deferred probe.
> I think it need to change jsut platform_driver_register()
> for ffa_driver.
>
Thanks for pointing that out. Forgot about that as I was focussing on keeping
it as simple as possible. I have updated the branch now.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Mimi Zohar @ 2026-05-06 11:47 UTC (permalink / raw)
To: Yeoreum Yun
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <afrXmRiq7XvSe6yN@e129823.arm.com>
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
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Yeoreum Yun @ 2026-05-06 13:57 UTC (permalink / raw)
To: Mimi Zohar
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <9ff4853a8e9932b3a1424f2a6c3347f1723fb5f4.camel@linux.ibm.com>
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
^ permalink raw reply related
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Mimi Zohar @ 2026-05-07 2:25 UTC (permalink / raw)
To: Paul Moore
Cc: Yeoreum Yun, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, jmorris,
serge, roberto.sassu, dmitry.kasatkin, eric.snowberg, jarkko, jgg,
sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, noodles, sebastianene
In-Reply-To: <19dfb0e2730.2843.85c95baa4474aabc7814e68940a78392@paul-moore.com>
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
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Mimi Zohar @ 2026-05-07 2:32 UTC (permalink / raw)
To: Yeoreum Yun
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <aftIuPwNeuzc9nY1@e129823.arm.com>
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
^ permalink raw reply
* Re: [PATCH v2] tpm: restore timeout for key creation commands
From: Zhang, Baoli @ 2026-05-07 5:36 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Peter Huewe, Jason Gunthorpe, Serge Hallyn, Lili Li,
linux-integrity, linux-kernel
In-Reply-To: <afi3hrjLm36qPc_T@kernel.org>
On 5/4/2026 11:13 PM, Jarkko Sakkinen wrote:
> On Tue, Apr 21, 2026 at 08:50:20AM +0800, Baoli Zhang wrote:
>> From: "Baoli Zhang" <baoli.zhang@linux.intel.com>
>>
>> Commit 207696b17f38 ("tpm: use a map for tpm2_calc_ordinal_duration()")
>> inadvertently reduced the timeout for TPM2 key creation commands
>> (`CREATE_PRIMARY`, `CREATE`, `CREATE_LOADED`) from 300 seconds to 30
>> seconds.
>>
>> This causes intermittent timeout failures, with several failures observed
>> across hundreds of test runs on some Intel platforms using Infineon
>> SLB9670 and SLB9672 TPM modules. Restore the timeout to 300 seconds to
>> avoid spurious failures.
> Is this a production case?
>
> I'm not sure if there is anything to fix tbh. I mean it is
> pretty much the same as "maintaining compatibility to OTT driver"
> to addresses issues on undisclosed hardware.
>
> Please correct me if I'm wrong. Otherwise, I'd carry out internal patch
> to tweak this for pre-production hardware (presumably).
Hi Jarkko, this is indeed a production case. We discovered this issue
during validation testing for the sustaining release.
>> Fixes: 207696b17f38 ("tpm: use a map for tpm2_calc_ordinal_duration()")
>> Co-developed-by: Lili Li <lili.li@intel.com>
>> Signed-off-by: Lili Li <lili.li@intel.com>
>> Signed-off-by: Baoli Zhang <baoli.zhang@linux.intel.com>
>> ---
>> Changes in v2:
>> - Add description of intermittent nature of the timeout issue.
>> - Fix Co-developed-by and Signed-off-by tag ordering.
>>
>> v1: https://patchwork.kernel.org/project/linux-integrity/patch/20260410014940.3557934-1-baoli.zhang@linux.intel.com/
>>
>> drivers/char/tpm/tpm2-cmd.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
>> index 3a77be7ebf4aa..430022f695f24 100644
>> --- a/drivers/char/tpm/tpm2-cmd.c
>> +++ b/drivers/char/tpm/tpm2-cmd.c
>> @@ -71,9 +71,9 @@ static const struct {
>> {TPM2_CC_HIERARCHY_CHANGE_AUTH, 2000},
>> {TPM2_CC_GET_CAPABILITY, 750},
>> {TPM2_CC_NV_READ, 2000},
>> - {TPM2_CC_CREATE_PRIMARY, 30000},
>> - {TPM2_CC_CREATE, 30000},
>> - {TPM2_CC_CREATE_LOADED, 30000},
>> + {TPM2_CC_CREATE_PRIMARY, 300000},
>> + {TPM2_CC_CREATE, 300000},
>> + {TPM2_CC_CREATE_LOADED, 300000},
>> };
>>
>> /**
>> --
>> 2.43.0
>>
> BR, Jarkko
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Yeoreum Yun @ 2026-05-07 5:50 UTC (permalink / raw)
To: Mimi Zohar
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <9d1af933ef218b159762884357d127e3644dfe2c.camel@linux.ibm.com>
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
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Roberto Sassu @ 2026-05-07 8:10 UTC (permalink / raw)
To: Mimi Zohar, Paul Moore
Cc: Yeoreum Yun, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, jmorris,
serge, roberto.sassu, dmitry.kasatkin, eric.snowberg, jarkko, jgg,
sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, noodles, sebastianene
In-Reply-To: <461ec995935e2b42a8414f6f87063ff2557bbfb4.camel@linux.ibm.com>
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
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Mimi Zohar @ 2026-05-07 11:28 UTC (permalink / raw)
To: Yeoreum Yun
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <afwoDgaJxmKwOhXp@e129823.arm.com>
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
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Yeoreum Yun @ 2026-05-07 12:41 UTC (permalink / raw)
To: Mimi Zohar
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <f19081f1eda19d6d1ae133d8ec93e779ab1a25e5.camel@linux.ibm.com>
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
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Mimi Zohar @ 2026-05-07 14:00 UTC (permalink / raw)
To: Roberto Sassu, Paul Moore
Cc: Yeoreum Yun, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, jmorris,
serge, roberto.sassu, dmitry.kasatkin, eric.snowberg, jarkko, jgg,
sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, noodles, sebastianene
In-Reply-To: <8c99263d8e63100e0b5e6c8cf739f7f6e7e79f6b.camel@huaweicloud.com>
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
^ permalink raw reply
* Re: [PATCH v5 00/13] ima: Introduce staging mechanism
From: steven chen @ 2026-05-07 16:47 UTC (permalink / raw)
To: Roberto Sassu, corbet, skhan, zohar, dmitry.kasatkin,
eric.snowberg, paul, jmorris, serge
Cc: linux-doc, linux-kernel, linux-integrity, linux-security-module,
gregorylumen, nramas, Roberto Sassu, steven chen
In-Reply-To: <20260429160319.4162918-1-roberto.sassu@huaweicloud.com>
On 4/29/2026 9:03 AM, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@huawei.com>
>
> Introduction
> ============
>
> The IMA measurements list is currently stored in the kernel memory.
> Memory occupation grows linearly with the number of entries, and can
> become a problem especially in environments with reduced resources.
>
> While there is an advantage in keeping the IMA measurements list in
> kernel memory, so that it is always available for reading from the
> securityfs interfaces, storing it elsewhere would make it possible to
> free precious memory for other kernel components.
>
> Storing the IMA measurements list outside the kernel does not introduce
> security issues, since its integrity is anyway protected by the TPM.
>
> Hence, the new IMA staging mechanism is introduced to allow user space
> to remove the desired portion of the measurements list from the kernel.
>
>
> Usage
> =====
>
> The IMA staging mechanism can be enabled from the kernel configuration
> with the CONFIG_IMA_STAGING option.
>
> If it is enabled, IMA duplicates the current measurements interfaces
> (both binary and ASCII), by adding the _staged file suffix. Both the
> original and the staging interfaces gain the write permission for the
> root user and group, but require the process to have CAP_SYS_ADMIN set.
>
> The staging mechanism supports two flavors.
>
> Staging with prompt
> ~~~~~~~~~~~~~~~~~~~
>
> The current measurements list is moved to a temporary staging area, and
> staged measurements are deleted upon confirmation.
>
> This staging process is achieved with the following steps.
>
> 1. echo A > <original interface>: the user requests IMA to stage the
> entire measurements list;
> 2. cat <_staged interface>: the user reads the staged measurements;
> 3. echo D > <_staged interface>: the user requests IMA to delete
> staged measurements.
>
> Staging and deleting
> ~~~~~~~~~~~~~~~~~~~~
>
> N measurements are staged to a temporary staging area, and immediately
> deleted without further confirmation.
>
> This staging process is achieved with the following steps.
>
> 1. cat <original interface>: the user reads the current measurements
> list and determines what the value N for staging should be;
> 2. echo N > <original interface>: the user requests IMA to delete N
> measurements from the current measurements list.
This submission proposes two ways for log trimming:
*Favour 1:* Staging with prompt
*Favour 2:* stage and delete N
Functionally, both approaches address the same problem, but *Favour 2
*is the
stronger design and should be preferred. There is no good reason to keep
*Favour 1.*
From a kernel implementation perspective, *Favour 2 *is more efficient
because it
minimizes the time spent holding the list lock (can’t be shorter). It
also substantially
reduces the amount of kernel-side logic, removing nearly half of the
code required
by the alternative approach.
From a user-space perspective, *Favour 2 *results in a much cleaner
model. It avoids
the need to track and reconcile both old and staged lists in user space
as well as
two lists (cur and staged) in the kernel space, which simplifies log
trimming logic
and reduces maintenance overhead. In addition, it preserves the existing
external
behavior by not exposing any staged list to user space.
Overall, *Favour 2 *provides the same functional result with lower
kernel complexity,
shorter kernel list lock hold time, and a simpler user-space interface.
For those
reasons, it is the preferable approach and *Favour 1* does not appear to
offer sufficient
justification to keep both implementations.
Steven
>
> Management of Staged Measurements
> =================================
>
> Since with the staging mechanism measurement entries are removed from
> the kernel, the user needs to save the staged ones in a storage and
> concatenate them together, so that it can present them to remote
> attestation agents as if staging was never done.
>
>
> Patch set content
> =================
>
> Patches 1-8 are preparatory patches to quickly replace the hash table,
> maintain separate counters for the different measurements list types,
> mediate access to the measurements list interface, and simplify the staging
> patches.
>
> Patch 9 introduces the staging with prompt flavor. Patch 10 makes it
> possible to flush the hash table when deleting all the staged measurements.
> Patch 11 introduces the staging and deleting flavor. Patch 12 avoids
> measurements entries to be stored twice if there is contention between the
> measurements interfaces and kexec. Patch 13 adds the documentation of the
> staging mechanism.
>
>
> Changelog
> =========
>
> v4:
> - Add write permission to the original measurement interface, and move
> the A and N staging commands to that interface
> - Explain better the two staging flavors and highlight that the staging
> and delete only stages measurements internally
> - Rename ima_queue_staged_delete_partial() to ima_queue_delete_partial()
> - Replace ima_staged_measurements_prepended with per measurements list
> flag to avoid copying staged and active list measurements twice
> - Optimize the staging and deleting flavor by locklessly determining the
> cut position in the active list, and immediately deleting entries
> without explicit staging and splicing (suggested by Steven Chen)
>
> v3:
> - Add Kconfig option to enable the staging mechanism (suggested by Mimi)
> - Change the meaning of BINARY_STAGED to be just the staged measurements
> - Separate the two staging flavors in two different functions:
> ima_queue_staged_delete_all() for staging with prompt,
> ima_queue_staged_delete_partial() for staging and deleting
> - Delete N entries without staging first (suggested by Mimi)
> - Avoid duplicate staged entries if there is contention between the
> measurements list interfaces and kexec
>
> v2:
> - New patch to move measurements and violation counters outside the
> ima_h_table structure
> - New patch to quickly replace the hash table
> - Forbid partial deletion when flushing hash table (suggested by Mimi)
> - Ignore ima_flush_htable if CONFIG_IMA_DISABLE_HTABLE is enabled
> - BINARY_SIZE_* renamed to BINARY_* for better clarity
> - Removed ima_measurements_staged_exist and testing list empty instead
> - ima_queue_stage_trim() and ima_queue_delete_staged_trimmed() renamed to
> ima_queue_stage() and ima_queue_delete_staged()
> - New delete interval [1, ULONG_MAX - 1]
> - Rename ima_measure_lock to ima_measure_mutex
> - Move seq_open() and seq_release() outside the ima_measure_mutex lock
> - Drop ima_measurements_staged_read() and use seq_read() instead
> - Optimize create_securityfs_measurement_lists() changes
> - New file name format with _staged suffix at the end of the file name
> - Use _rcu list variant in ima_dump_measurement_list()
> - Remove support for direct trimming and splice the remaining entries to
> the active list (suggested by Mimi)
> - Hot swap the hash table if flushing is requested
>
> v1:
> - Support for direct trimming without staging
> - Support unstaging on kexec (requested by Gregory Lumen)
>
> Roberto Sassu (13):
> ima: Remove ima_h_table structure
> ima: Replace static htable queue with dynamically allocated array
> ima: Introduce per binary measurements list type ima_num_entries
> counter
> ima: Introduce per binary measurements list type binary_runtime_size
> value
> ima: Introduce _ima_measurements_start() and _ima_measurements_next()
> ima: Mediate open/release method of the measurements list
> ima: Use snprintf() in create_securityfs_measurement_lists
> ima: Introduce ima_dump_measurement()
> ima: Add support for staging measurements with prompt
> ima: Add support for flushing the hash table when staging measurements
> ima: Support staging and deleting N measurements entries
> ima: Return error on deleting measurements already copied during kexec
> doc: security: Add documentation of the IMA staging mechanism
>
> .../admin-guide/kernel-parameters.txt | 4 +
> Documentation/security/IMA-staging.rst | 163 +++++++++
> Documentation/security/index.rst | 1 +
> MAINTAINERS | 2 +
> security/integrity/ima/Kconfig | 16 +
> security/integrity/ima/ima.h | 32 +-
> security/integrity/ima/ima_api.c | 2 +-
> security/integrity/ima/ima_fs.c | 315 ++++++++++++++++--
> security/integrity/ima/ima_init.c | 5 +
> security/integrity/ima/ima_kexec.c | 53 ++-
> security/integrity/ima/ima_queue.c | 283 ++++++++++++++--
> 11 files changed, 803 insertions(+), 73 deletions(-)
> create mode 100644 Documentation/security/IMA-staging.rst
>
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Yeoreum Yun @ 2026-05-07 20:03 UTC (permalink / raw)
To: Mimi Zohar
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <afyIbW5cljh5ZvTL@e129823.arm.com>
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
^ permalink raw reply
* [PATCH] tpm: Fix uninitialized name_size_alg in tpm_buf_append_name()
From: Gunnar Kudrjavets @ 2026-05-07 20:18 UTC (permalink / raw)
To: peterhuewe, jarkko
Cc: jgg, noodles, gunnarku, linux-integrity, linux-kernel,
Justinien Bouron, Muhammad Hammad Ijaz
When tpm_buf_append_name() is called with a non-NULL name for a
handle, the code skips the tpm2_read_public() path (which sets
name_size_alg from the return value) and falls through to memcpy()
with an uninitialized name_size_alg as the size argument.
The contract for tpm_buf_append_name() supports callers passing a
non-NULL name. No current in-tree callers do so, making this a latent
bug that would trigger if a caller ever provides a pre-computed name
for a handle.
Fix this by restructuring the if/else to call name_size() when name
is provided, sharing the error check and name_size_alg assignment
with the existing tpm2_read_public() path. This restores the type of
validation that existed before commit bda1cbf73c6e ("tpm2-sessions:
Fix tpm2_read_public range checks") refactored the function.
Tested with KASAN by assigning 0xDEAD to name_size_alg to simulate an
undefined initial value. Calling tpm_buf_append_name() with a non-NULL
value for name results in the following warnings from KASAN:
BUG: KASAN: stack-out-of-bounds in tpm_buf_append_name+0x1e0/0x680
Read of size 57005 at addr ffff80009e5e79f0 by task sh/49616
Call trace:
show_stack+0x34/0xa0 (C)
dump_stack_lvl+0x5c/0x80
print_report+0x160/0x4b8
kasan_report+0x7c/0xd0
kasan_check_range+0xe8/0x190
__asan_memcpy+0x3c/0xa0
tpm_buf_append_name+0x1e0/0x680
run_test.isra.0+0x14c/0x1d8
There are no KASAN errors with the fix applied, and the function
behaves as expected.
Fixes: bda1cbf73c6e ("tpm2-sessions: Fix tpm2_read_public range checks")
Assisted-by: Kiro:claude-opus-4.6
Reviewed-by: Justinien Bouron <jbouron@amazon.com>
Reviewed-by: Muhammad Hammad Ijaz <mhijaz@amazon.com>
Signed-off-by: Gunnar Kudrjavets <gunnarku@amazon.com>
---
drivers/char/tpm/tpm2-sessions.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tpm/tpm2-sessions.c b/drivers/char/tpm/tpm2-sessions.c
index c4da6fde748f..795cd99dc6fe 100644
--- a/drivers/char/tpm/tpm2-sessions.c
+++ b/drivers/char/tpm/tpm2-sessions.c
@@ -285,11 +285,14 @@ int tpm_buf_append_name(struct tpm_chip *chip, struct tpm_buf *buf,
mso == TPM2_MSO_NVRAM) {
if (!name) {
ret = tpm2_read_public(chip, handle, auth->name[slot]);
- if (ret < 0)
- goto err;
-
- name_size_alg = ret;
+ } else {
+ ret = name_size(name);
}
+
+ if (ret < 0)
+ goto err;
+
+ name_size_alg = ret;
} else {
if (name) {
dev_err(&chip->dev, "handle 0x%08x does not use a name\n",
base-commit: 9ec4175a30eb5adb95e446af83ddf6cb3286a82a
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Mimi Zohar @ 2026-05-07 21:36 UTC (permalink / raw)
To: Yeoreum Yun
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <afzwJn+5r15jFxrB@e129823.arm.com>
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
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Yeoreum Yun @ 2026-05-08 9:06 UTC (permalink / raw)
To: Mimi Zohar
Cc: David Safford, Jonathan McDowell, linux-security-module,
linux-kernel, linux-integrity, linux-arm-kernel, kvmarm, paul,
jmorris, serge, roberto.sassu, dmitry.kasatkin, eric.snowberg,
jarkko, jgg, sudeep.holla, maz, oupton, joey.gouly,
suzuki.poulose, yuzenghui, catalin.marinas, will, noodles,
sebastianene
In-Reply-To: <77ad49cca1acf707f4152ed3e2066b2f24c90c16.camel@linux.ibm.com>
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox