* 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-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: [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: [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: 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: 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 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: 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 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: 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: [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: [PATCH] ima: debugging late_initcall_sync measurements
From: Yeoreum Yun @ 2026-05-06 5:54 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: <201b9172ac47c6766443c1f2343cab3548f33c29.camel@linux.ibm.com>
Hi Mimi,
> On Sun, 2026-05-03 at 07:36 -0400, Mimi Zohar wrote:
> > On Fri, 2026-05-01 at 12:52 -0400, David Safford wrote:
> > > On Thu, Apr 30, 2026 at 5:43 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > >
> > > > On Thu, 2026-04-30 at 10:48 +0100, Yeoreum Yun wrote:
> > > > > With above change I confirmed there is no meaurement log
> > > > > between boot_aggregate and boot_aggregate_late except "kernel_version"
> > > > > But this is ignorable since this UTS measurement is done in
> > > > > "ima_init_core() (old: ima_init())" and it is part of ima initialisation.
> > > > >
> > > > > 1. ima_policy=tcb
> > > > >
> > > > > # cat /sys/kernel/security/ima/ascii_runtime_measurements
> > > > > 10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
> > > > > 10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
> > > > > 10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox
> > > snip
> > > > >
> > > > > 2. ima_policy=critical_data
> > > > >
> > > > > # cat /sys/kernel/security/ima/ascii_runtime_measurements
> > > > > 10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
> > > > > 10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
> > > > > 10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
> > > > >
> > > > > Therefore, init_ima() could move into late_initcall_sync like v1 did:
> > > > > - https://lore.kernel.org/all/20260417175759.3191279-2-yeoreum.yun@arm.com/
> > > >
> > > > Thanks, Yeoreum. It's a bit premature to claim it's "safe" to move the
> > > > initcall. Hopefully others will respond.
> > > >
> > > > Mimi
> > >
> > > I have also run with this patch on a number of bare metal and virtual machines,
> > > running everything from default Fedora 44 to a version with everything turned on
> > > (uefi secure boot, UKI with sdboot stub measurements, IMA measurement
> > > and appraisal enabled,
> > > all systemd measurements on, and systemd using the TPM for root
> > > partition decryption.)
> > > I too see only the kernel_version event between the normal and late
> > > calls, if ima_policy=critical_data.
> >
> > Thanks, Dave! Were all the systems you tested x86_64? The next step would be
> > to test on different arch's (e.g. Z, Power).
>
> On both Z and PowerVM, there are ~30 measurements between boot_aggregate and
> boot_aggregate_late. For example, on PowerVM:
>
> # grep -n boot_aggregate
> /sys/kernel/security/integrity/ima/ascii_runtime_measurements
>
> 1:10 f60a05d7354fb34aabc02965216abd3428ea52bb ima-sig
> sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> boot_aggregate
> 31:10 e2592b0d61da6300d3db447b143897a9792231ea ima-sig
> sha256:9887dd089ee19a6517bca10580b02c1bb9aa6cd86c157b6ead8a1c0403f348d5
> boot_aggregate_late
>
> It would be interesting to the results from a Raspberry Pi 5 as well,
> with/without a TPM.
Honestly, I find this result hard to accept.
This effectively means that there is code invoking IMA measurement during late_initcall().
It also implies that if, in the future, a late_initcall is added that performs
an IMA measurement before IMA initialization has occurred accoding to order by linker,
that measurement could be missed.
Could you please check how the index (1, 31) was added to either
ima_template_entry or ima_queue_entry to produce this result?
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* [PATCH] Documentation: fix typo and formattting in security/credentials.rst
From: Mayank Gite @ 2026-05-06 5:49 UTC (permalink / raw)
To: Paul Moore
Cc: Mayank Gite, Serge Hallyn, Jonathan Corbet, Shuah Khan,
linux-security-module, linux-doc, linux-kernel
- Fixes a typo in "Keys and keyrings" section. Replaces "keying" with
"keyring".
- Updates formatting of keyring types.
Signed-off-by: Mayank Gite <drapl0n@protonmail.com>
---
Documentation/security/credentials.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/security/credentials.rst b/Documentation/security/credentials.rst
index d0191c8b8060..4996838491b1 100644
--- a/Documentation/security/credentials.rst
+++ b/Documentation/security/credentials.rst
@@ -189,9 +189,9 @@ The Linux kernel supports the following types of credentials:
be searched for the desired key. Each process may subscribe to a number
of keyrings:
- Per-thread keying
- Per-process keyring
- Per-session keyring
+ - Per-thread keyring
+ - Per-process keyring
+ - Per-session keyring
When a process accesses a key, if not already present, it will normally be
cached on one of these keyrings for future accesses to find.
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Paul Moore @ 2026-05-06 2:11 UTC (permalink / raw)
To: Mimi Zohar
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: <5debff82dc758d9c91223e4f1f5b9e39a3fcd4f5.camel@linux.ibm.com>
On May 5, 2026 9:57:23 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Tue, 2026-05-05 at 18:55 -0400, Paul Moore wrote:
>> On Tue, May 5, 2026 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>> On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
>>>> On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>>>>> On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
>>>>>> Regardless, assuming you always want IMA to leverage a TPMs when they
>>>>>> exist, your reply suggests that using an initcall based IMA init
>>>>>> scheme, even a late-sync initcall, may not be sufficient because
>>>>>> deferred TPM initialization could happen later, yes?
>>>>>
>>>>> Well yeah. The TPM could be configured as a module, but that scenario is
>>>>> not of
>>>>> interest. That's way too late. The case being addressed in this patch set is
>>>>> when the TPM driver tries to initialize at device_initcall, returns
>>>>> EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since
>>>>> ordering within an initcall is not supported, this patch attempts to initialize
>>>>> IMA at late_initcall and similarly retries, in this case, at
>>>>> late_initcall_sync.
>>>>
>>>> Okay, so from a TPM initialization perspective you are satisfied with
>>>> a late-sync IMA initialization, yes?
>>>
>>> No. On some architectures moving IMA initialization from the late_initcall to
>>> late_initcall_sync does not miss any measurement records. However, as
>>> previously
>>> mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
>>> records[1]. So no, only if the TPM is not initialized by late_initcall, should
>>> IMA retry at late_initcall_sync.
>>
>> What do you do in the PowerVM LPAR when the TPM is not avaiable at
>> late initcall and you have to defer IMA initialization until
>> late-sync?
>
> Your question is hypothetical ...
<heavy eye roll>
> ... as the TPM isn't deferred, so IMA doesn't go into
> TPM-bypass mode. Testing on a PowerVM LPAR demonstrated that it skips ~30
> measurement list records. So moving the initcall to late_initcall_sync would
> cause a regression.
Let me rephrase to make the question clear - how do you plan to handle a
system where you lose measurements by waiting until late-sync, but the TPM
is not available at the late initcall.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Mimi Zohar @ 2026-05-06 1:51 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: <CAHC9VhRUgNA=Sj=jhD=zOt8R80Q+FQj+H0nYSy-FAujTL3EKPA@mail.gmail.com>
On Tue, 2026-05-05 at 18:55 -0400, Paul Moore wrote:
> On Tue, May 5, 2026 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
> > > On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > > On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
> > > > > Regardless, assuming you always want IMA to leverage a TPMs when they
> > > > > exist, your reply suggests that using an initcall based IMA init
> > > > > scheme, even a late-sync initcall, may not be sufficient because
> > > > > deferred TPM initialization could happen later, yes?
> > > >
> > > > Well yeah. The TPM could be configured as a module, but that scenario is not of
> > > > interest. That's way too late. The case being addressed in this patch set is
> > > > when the TPM driver tries to initialize at device_initcall, returns
> > > > EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since
> > > > ordering within an initcall is not supported, this patch attempts to initialize
> > > > IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.
> > >
> > > Okay, so from a TPM initialization perspective you are satisfied with
> > > a late-sync IMA initialization, yes?
> >
> > No. On some architectures moving IMA initialization from the late_initcall to
> > late_initcall_sync does not miss any measurement records. However, as previously
> > mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
> > records[1]. So no, only if the TPM is not initialized by late_initcall, should
> > IMA retry at late_initcall_sync.
>
> What do you do in the PowerVM LPAR when the TPM is not avaiable at
> late initcall and you have to defer IMA initialization until
> late-sync?
Your question is hypothetical, as the TPM isn't deferred, so IMA doesn't go into
TPM-bypass mode. Testing on a PowerVM LPAR demonstrated that it skips ~30
measurement list records. So moving the initcall to late_initcall_sync would
cause a regression.
Mimi
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Paul Moore @ 2026-05-05 22:55 UTC (permalink / raw)
To: Mimi Zohar
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: <a9412fe10e70ce95dd70556ace19368bec5c188c.camel@linux.ibm.com>
On Tue, May 5, 2026 at 5:05 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
> > On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > > On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
> > > > Regardless, assuming you always want IMA to leverage a TPMs when they
> > > > exist, your reply suggests that using an initcall based IMA init
> > > > scheme, even a late-sync initcall, may not be sufficient because
> > > > deferred TPM initialization could happen later, yes?
> > >
> > > Well yeah. The TPM could be configured as a module, but that scenario is not of
> > > interest. That's way too late. The case being addressed in this patch set is
> > > when the TPM driver tries to initialize at device_initcall, returns
> > > EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since
> > > ordering within an initcall is not supported, this patch attempts to initialize
> > > IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.
> >
> > Okay, so from a TPM initialization perspective you are satisfied with
> > a late-sync IMA initialization, yes?
>
> No. On some architectures moving IMA initialization from the late_initcall to
> late_initcall_sync does not miss any measurement records. However, as previously
> mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
> records[1]. So no, only if the TPM is not initialized by late_initcall, should
> IMA retry at late_initcall_sync.
What do you do in the PowerVM LPAR when the TPM is not avaiable at
late initcall and you have to defer IMA initialization until
late-sync?
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Mimi Zohar @ 2026-05-05 21:02 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: <CAHC9VhQY2TMkTvQq9P8oZteQWQSr7qq2utOuH+pdVx+8jWLBCw@mail.gmail.com>
On Mon, 2026-05-04 at 16:51 -0400, Paul Moore wrote:
> On Mon, May 4, 2026 at 8:03 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > On Sun, 2026-05-03 at 12:46 -0400, Paul Moore wrote:
> > > Regardless, assuming you always want IMA to leverage a TPMs when they
> > > exist, your reply suggests that using an initcall based IMA init
> > > scheme, even a late-sync initcall, may not be sufficient because
> > > deferred TPM initialization could happen later, yes?
> >
> > Well yeah. The TPM could be configured as a module, but that scenario is not of
> > interest. That's way too late. The case being addressed in this patch set is
> > when the TPM driver tries to initialize at device_initcall, returns
> > EPROBE_DEFER, and is retried at deferred_probe_initcall (late_initcall). Since
> > ordering within an initcall is not supported, this patch attempts to initialize
> > IMA at late_initcall and similarly retries, in this case, at late_initcall_sync.
>
> Okay, so from a TPM initialization perspective you are satisfied with
> a late-sync IMA initialization, yes?
No. On some architectures moving IMA initialization from the late_initcall to
late_initcall_sync does not miss any measurement records. However, as previously
mentioned, Linux running in a PowerVM LPAR the move would drop ~30 measurement
records[1]. So no, only if the TPM is not initialized by late_initcall, should
IMA retry at late_initcall_sync.
Mimi
[1]
https://lore.kernel.org/linux-integrity/201b9172ac47c6766443c1f2343cab3548f33c29.camel@linux.ibm.com/
^ permalink raw reply
* Re: [PATCH v5 11/13] ima: Support staging and deleting N measurements entries
From: steven chen @ 2026-05-05 18:43 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-12-roberto.sassu@huaweicloud.com>
On 4/29/2026 9:03 AM, Roberto Sassu wrote:
> From: Roberto Sassu <roberto.sassu@huawei.com>
>
> Add support for sending a value N between 1 and ULONG_MAX to the IMA
> original measurement interface. This value represents the number of
> measurements that should be deleted from the current measurements list. In
> this case, measurements are staged in an internal non-user visible list,
> and immediately deleted.
>
> This staging method allows the remote attestation agents to easily separate
> the measurements that were verified (staged and deleted) from those that
> weren't due to the race between taking a TPM quote and reading the
> measurements list.
>
> In order to minimize the locking time of ima_extend_list_mutex, deleting
> N entries is realized by doing a lockless walk in the current measurements
> list to determine the N-th entry to cut, to cut the current measurements
> list under the lock, and by deleting the excess entries after releasing the
> lock.
>
> Flushing the hash table is not supported for N entries, since it would
> require removing the N entries one by one from the hash table under the
> ima_extend_list_mutex lock, which would increase the locking time.
>
> The ima_extend_list_mutex lock is necessary in ima_dump_measurement_list()
> because ima_queue_delete_partial() uses __list_cut_position() to modify
> ima_measurements, for which no RCU-safe variant exists. For the staging
> with prompt flavor alone, list_replace_rcu() could have been used instead,
> but since both flavors share the same kexec serialization path, the mutex
> is required regardless.
This submit provides two ways for trimming logs:
Patch 9: stage and delete
This patch 11: stage and delete N
Both are doing the same thing in different ways
I think the best way is just keep the patch 11 for following reasons:
Kernel list lock time is minimum
Kernel code change will be much simpler (almost half gone)
User space processing for log trimming is much simpler
no need to maintain two lists (old and staged) in user space
No two lists seen from user space (same as before)
no staged list shown
Steven
> Link: https://github.com/linux-integrity/linux/issues/1
> Suggested-by: Steven Chen <chenste@linux.microsoft.com>
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> ---
> security/integrity/ima/Kconfig | 3 +++
> security/integrity/ima/ima.h | 1 +
> security/integrity/ima/ima_fs.c | 21 ++++++++++++++-
> security/integrity/ima/ima_kexec.c | 3 ++-
> security/integrity/ima/ima_queue.c | 43 ++++++++++++++++++++++++++++++
> 5 files changed, 69 insertions(+), 2 deletions(-)
>
> diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
> index 48c906793efb..4f4373859a4f 100644
> --- a/security/integrity/ima/Kconfig
> +++ b/security/integrity/ima/Kconfig
> @@ -341,6 +341,9 @@ config IMA_STAGING
> It allows user space to stage the measurements list for deletion and
> to delete the staged measurements after confirmation.
>
> + Or, alternatively, it allows user space to specify N measurements
> + entries to stage internally, so that they can be immediately deleted.
> +
> On kexec, staging is reverted and staged measurements are prepended
> to the current measurements list when measurements are copied to the
> secondary kernel.
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index 4af66c1de4dc..9a741b33d524 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -320,6 +320,7 @@ struct ima_template_desc *lookup_template_desc(const char *name);
> bool ima_template_has_modsig(const struct ima_template_desc *ima_template);
> int ima_queue_stage(void);
> int ima_queue_staged_delete_all(void);
> +int ima_queue_delete_partial(unsigned long req_value);
> int ima_restore_measurement_entry(struct ima_template_entry *entry);
> int ima_restore_measurement_list(loff_t bufsize, void *buf);
> int ima_measurements_show(struct seq_file *m, void *v);
> diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
> index 088d5a69aa92..6843dc203b54 100644
> --- a/security/integrity/ima/ima_fs.c
> +++ b/security/integrity/ima/ima_fs.c
> @@ -28,6 +28,7 @@
> * Requests:
> * 'A\n': stage the entire measurements list
> * 'D\n': delete all staged measurements
> + * '[1, ULONG_MAX]\n' delete N measurements entries
> */
> #define STAGED_REQ_LENGTH 21
>
> @@ -312,6 +313,7 @@ static ssize_t _ima_measurements_write(struct file *file,
> loff_t *ppos, bool staged_interface)
> {
> char req[STAGED_REQ_LENGTH];
> + unsigned long req_value;
> int ret;
>
> if (*ppos > 0 || datalen < 2 || datalen > STAGED_REQ_LENGTH)
> @@ -339,7 +341,24 @@ static ssize_t _ima_measurements_write(struct file *file,
> ret = ima_queue_staged_delete_all();
> break;
> default:
> - ret = -EINVAL;
> + if (staged_interface)
> + return -EINVAL;
> +
> + if (ima_flush_htable) {
> + pr_debug("Deleting staged N measurements not supported when flushing the hash table is requested\n");
> + return -EINVAL;
> + }
> +
> + ret = kstrtoul(req, 10, &req_value);
> + if (ret < 0)
> + return ret;
> +
> + if (req_value == 0) {
> + pr_debug("Must delete at least one entry\n");
> + return -EINVAL;
> + }
> +
> + ret = ima_queue_delete_partial(req_value);
> }
>
> if (ret < 0)
> diff --git a/security/integrity/ima/ima_kexec.c b/security/integrity/ima/ima_kexec.c
> index 064cfce0c318..e7bde3d917b2 100644
> --- a/security/integrity/ima/ima_kexec.c
> +++ b/security/integrity/ima/ima_kexec.c
> @@ -107,7 +107,8 @@ static int ima_dump_measurement_list(unsigned long *buffer_size, void **buffer,
> memset(&khdr, 0, sizeof(khdr));
> khdr.version = 1;
> /*
> - * It can race with ima_queue_stage() and ima_queue_staged_delete_all().
> + * It can race with ima_queue_stage(), ima_queue_staged_delete_all()
> + * and ima_queue_delete_partial().
> */
> mutex_lock(&ima_extend_list_mutex);
>
> diff --git a/security/integrity/ima/ima_queue.c b/security/integrity/ima/ima_queue.c
> index f5c18acfbc43..64c4fe73dd5f 100644
> --- a/security/integrity/ima/ima_queue.c
> +++ b/security/integrity/ima/ima_queue.c
> @@ -371,6 +371,49 @@ int ima_queue_staged_delete_all(void)
> return 0;
> }
>
> +int ima_queue_delete_partial(unsigned long req_value)
> +{
> + unsigned long req_value_copy = req_value;
> + unsigned long size_to_remove = 0, num_to_remove = 0;
> + LIST_HEAD(ima_measurements_trim);
> + struct ima_queue_entry *qe;
> + int ret = 0;
> +
> + /*
> + * Safe to walk without rcu_read_lock(): single-writer
> + * exclusion in ima_fs.c prevents any concurrent modification
> + * to ima_measurements during this walk.
> + */
> + list_for_each_entry_rcu(qe, &ima_measurements, later, true) {
> + size_to_remove += get_binary_runtime_size(qe->entry);
> + num_to_remove++;
> +
> + if (--req_value_copy == 0)
> + break;
> + }
> +
> + /* Not enough entries to delete. */
> + if (req_value_copy > 0)
> + return -ENOENT;
> +
> + mutex_lock(&ima_extend_list_mutex);
> + /*
> + * qe remains valid because ima_fs.c enforces single-writer exclusion.
> + */
> + __list_cut_position(&ima_measurements_trim, &ima_measurements,
> + &qe->later);
> +
> + atomic_long_sub(num_to_remove, &ima_num_entries[BINARY]);
> +
> + if (IS_ENABLED(CONFIG_IMA_KEXEC))
> + binary_runtime_size[BINARY] -= size_to_remove;
> +
> + mutex_unlock(&ima_extend_list_mutex);
> +
> + ima_queue_delete(&ima_measurements_trim, false);
> + return ret;
> +}
> +
> static void ima_queue_delete(struct list_head *head, bool flush_htable)
> {
> struct ima_queue_entry *qe, *qe_tmp;
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Yeoreum Yun @ 2026-05-05 16: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: <20260505-adaptable-mussel-of-virtuosity-2751db@sudeepholla>
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)
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?
[...]
--
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-05 16:32 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-integrity, keyrings, Sudeep Holla, 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: <afoHizU8NgFWzvYW@e129823.arm.com>
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).
Regards,
Sudeep
-->8
firmware: arm_ffa: Register core as a platform driver
Move the FF-A core bring-up and teardown paths into platform driver
probe and remove callbacks, and register a synthetic arm-ffa platform
device to bind the driver.
This makes the FF-A core lifetime follow the driver model while keeping
the device creation internal to the FF-A core. The probe path can now
return normal driver-model errors, including probe deferral when pKVM is
enabled but not yet initialized.
Since the transport selection now happens from the platform probe path,
drop the __init annotation from ffa_transport_init().
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/common.h | 4 +--
drivers/firmware/arm_ffa/driver.c | 55 +++++++++++++++++++++++++++----
drivers/firmware/arm_ffa/smccc.c | 2 +-
3 files changed, 52 insertions(+), 9 deletions(-)
diff --git a/drivers/firmware/arm_ffa/common.h b/drivers/firmware/arm_ffa/common.h
index 9c6425a81d0d..5cdf4bd222c6 100644
--- a/drivers/firmware/arm_ffa/common.h
+++ b/drivers/firmware/arm_ffa/common.h
@@ -18,9 +18,9 @@ bool ffa_device_is_valid(struct ffa_device *ffa_dev);
void ffa_device_match_uuid(struct ffa_device *ffa_dev, const uuid_t *uuid);
#ifdef CONFIG_ARM_FFA_SMCCC
-int __init ffa_transport_init(ffa_fn **invoke_ffa_fn);
+int ffa_transport_init(ffa_fn **invoke_ffa_fn);
#else
-static inline int __init ffa_transport_init(ffa_fn **invoke_ffa_fn)
+static inline int ffa_transport_init(ffa_fn **invoke_ffa_fn)
{
return -EOPNOTSUPP;
}
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index eb2782848283..d000727889f4 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -36,6 +36,7 @@
#include <linux/mm.h>
#include <linux/mutex.h>
#include <linux/of_irq.h>
+#include <linux/platform_device.h>
#include <linux/scatterlist.h>
#include <linux/slab.h>
#include <linux/smp.h>
@@ -46,6 +47,7 @@
#define FFA_DRIVER_VERSION FFA_VERSION_1_2
#define FFA_MIN_VERSION FFA_VERSION_1_0
+#define FFA_PLATFORM_NAME "arm-ffa"
#define SENDER_ID_MASK GENMASK(31, 16)
#define RECEIVER_ID_MASK GENMASK(15, 0)
@@ -114,6 +116,7 @@ struct ffa_drv_info {
};
static struct ffa_drv_info *drv_info;
+static struct platform_device *ffa_pdev;
/*
* The driver must be able to support all the versions from the earliest
@@ -2029,12 +2032,15 @@ static void ffa_notifications_setup(void)
ffa_notifications_cleanup();
}
-static int __init ffa_init(void)
+static int ffa_probe(struct platform_device *pdev)
{
int ret;
u32 buf_sz;
size_t rxtx_bufsz = SZ_4K;
+ if (is_protected_kvm_enabled() && !is_pkvm_initialized())
+ return -EPROBE_DEFER;
+
ret = ffa_transport_init(&invoke_ffa_fn);
if (ret)
return ret;
@@ -2042,6 +2048,7 @@ static int __init ffa_init(void)
drv_info = kzalloc_obj(*drv_info);
if (!drv_info)
return -ENOMEM;
+ platform_set_drvdata(pdev, drv_info);
ret = ffa_version_check(&drv_info->version);
if (ret)
@@ -2103,19 +2110,55 @@ static int __init ffa_init(void)
free_pages_exact(drv_info->tx_buffer, rxtx_bufsz);
free_pages_exact(drv_info->rx_buffer, rxtx_bufsz);
free_drv_info:
+ platform_set_drvdata(pdev, NULL);
kfree(drv_info);
+ drv_info = NULL;
return ret;
}
-rootfs_initcall(ffa_init);
-static void __exit ffa_exit(void)
+static void ffa_remove(struct platform_device *pdev)
{
+ struct ffa_drv_info *info = platform_get_drvdata(pdev);
+
ffa_notifications_cleanup();
ffa_partitions_cleanup();
ffa_rxtx_unmap();
- free_pages_exact(drv_info->tx_buffer, drv_info->rxtx_bufsz);
- free_pages_exact(drv_info->rx_buffer, drv_info->rxtx_bufsz);
- kfree(drv_info);
+ free_pages_exact(info->tx_buffer, info->rxtx_bufsz);
+ free_pages_exact(info->rx_buffer, info->rxtx_bufsz);
+ kfree(info);
+ platform_set_drvdata(pdev, NULL);
+ drv_info = NULL;
+}
+
+static struct platform_driver ffa_driver = {
+ .remove = ffa_remove,
+ .driver = {
+ .name = FFA_PLATFORM_NAME,
+ },
+};
+
+static int __init ffa_init(void)
+{
+ int ret;
+
+ ffa_pdev = platform_device_register_simple(FFA_PLATFORM_NAME,
+ PLATFORM_DEVID_NONE,
+ NULL, 0);
+ if (IS_ERR(ffa_pdev))
+ return PTR_ERR(ffa_pdev);
+
+ ret = platform_driver_probe(&ffa_driver, ffa_probe);
+ if (ret)
+ platform_device_unregister(ffa_pdev);
+
+ return ret;
+}
+module_init(ffa_init);
+
+static void __exit ffa_exit(void)
+{
+ platform_device_unregister(ffa_pdev);
+ platform_driver_unregister(&ffa_driver);
}
module_exit(ffa_exit);
diff --git a/drivers/firmware/arm_ffa/smccc.c b/drivers/firmware/arm_ffa/smccc.c
index 4d85bfff0a4e..e6125dd9f58f 100644
--- a/drivers/firmware/arm_ffa/smccc.c
+++ b/drivers/firmware/arm_ffa/smccc.c
@@ -17,7 +17,7 @@ static void __arm_ffa_fn_hvc(ffa_value_t args, ffa_value_t *res)
arm_smccc_1_2_hvc(&args, res);
}
-int __init ffa_transport_init(ffa_fn **invoke_ffa_fn)
+int ffa_transport_init(ffa_fn **invoke_ffa_fn)
{
enum arm_smccc_conduit conduit;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 04/14] security/Kconfig.hardening: Remove tautological condition from CC_HAS_RANDSTRUCT
From: Nicolas Schier @ 2026-05-05 15:28 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Bill Wendling, Justin Stitt, Nick Desaulniers, linux-kernel, llvm,
linux-kbuild, Kees Cook, Gustavo A. R. Silva, linux-hardening,
linux-security-module
In-Reply-To: <20260428-bump-minimum-supported-llvm-version-to-17-v1-4-81d9b2e8ee75@kernel.org>
On Tue, Apr 28, 2026 at 10:59:10PM -0400, Nathan Chancellor wrote:
> Now that the minimum supported version of LLVM for building the kernel
> has been raised to 17.0.1, the '!Clang || Clang >= 16' dependency for
> CONFIG_CC_HAS_RANDSTRUCT is always true, so it can be removed.
>
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> Cc: Kees Cook <kees@kernel.org>
> Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
> Cc: linux-hardening@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> ---
> security/Kconfig.hardening | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
> index e4f23c08a17a..b90cf9ed4642 100644
> --- a/security/Kconfig.hardening
> +++ b/security/Kconfig.hardening
> @@ -274,9 +274,6 @@ endmenu
>
> config CC_HAS_RANDSTRUCT
> def_bool $(cc-option,-frandomize-layout-seed-file=/dev/null)
> - # Randstruct was first added in Clang 15, but it isn't safe to use until
> - # Clang 16 due to https://github.com/llvm/llvm-project/issues/60349
> - depends on !CC_IS_CLANG || CLANG_VERSION >= 160000
>
> choice
> prompt "Randomize layout of sensitive kernel structures"
>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
^ permalink raw reply
* Re: [PATCH 03/14] security/Kconfig.hardening: Remove tautological condition from FORTIFY_SOURCE
From: Nicolas Schier @ 2026-05-05 15:28 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Bill Wendling, Justin Stitt, Nick Desaulniers, linux-kernel, llvm,
linux-kbuild, Kees Cook, Gustavo A. R. Silva, linux-hardening,
linux-security-module
In-Reply-To: <20260428-bump-minimum-supported-llvm-version-to-17-v1-3-81d9b2e8ee75@kernel.org>
On Tue, Apr 28, 2026 at 10:59:09PM -0400, Nathan Chancellor wrote:
> Now that the minimum supported version of LLVM for building the kernel
> has been raised to 17.0.1, the '!X86_32 || !Clang || Clang > 16'
> dependency of CONFIG_FORTIFY_SOURCE is always true, so it can be
> removed.
>
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> Cc: Kees Cook <kees@kernel.org>
> Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
> Cc: linux-hardening@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> ---
> security/Kconfig.hardening | 2 --
> 1 file changed, 2 deletions(-)
>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
^ permalink raw reply
* Re: [PATCH 02/14] security/Kconfig.hardening: Remove tautological condition from CC_HAS_ZERO_CALL_USED_REGS
From: Nicolas Schier @ 2026-05-05 15:28 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Bill Wendling, Justin Stitt, Nick Desaulniers, linux-kernel, llvm,
linux-kbuild, Kees Cook, Gustavo A. R. Silva, linux-hardening,
linux-security-module
In-Reply-To: <20260428-bump-minimum-supported-llvm-version-to-17-v1-2-81d9b2e8ee75@kernel.org>
On Tue, Apr 28, 2026 at 10:59:08PM -0400, Nathan Chancellor wrote:
> Now that the minimum supported version of LLVM for building the kernel
> has been raised to 17.0.1, the '!Clang || Clang > 15.0.6' dependency for
> CONFIG_CC_HAS_ZERO_CALL_USED_REGS is always true, so it can be removed.
>
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> Cc: Kees Cook <kees@kernel.org>
> Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
> Cc: linux-hardening@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> ---
> security/Kconfig.hardening | 3 ---
> 1 file changed, 3 deletions(-)
>
Reviewed-by: Nicolas Schier <nsc@kernel.org>
^ permalink raw reply
* Re: [RFC PATCH 2/3] firmware: arm_ffa: initialise ff-a after finalising pKVM initialisation
From: Yeoreum Yun @ 2026-05-05 15:06 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: <20260505-super-gecko-of-argument-655030@sudeepholla>
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?
Thanks!
> --
> Regards,
> Sudeep
--
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-05 14:39 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-integrity, keyrings, Sudeep Holla, 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: <20260505095409.1948371-3-yeoreum.yun@arm.com>
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 ?
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.
--
Regards,
Sudeep
^ 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