* 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
* Re: [PATCH v2 1/2] bpf: add bpf_init_inode_xattr kfunc for atomic inode labeling
From: Paul Moore @ 2026-05-05 13:49 UTC (permalink / raw)
To: Song Liu
Cc: David Windsor, Alexander Viro, Christian Brauner,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, KP Singh,
Matt Bobrowski, James Morris, Serge E. Hallyn, Mimi Zohar,
Roberto Sassu, Dmitry Kasatkin, Stephen Smalley, Casey Schaufler,
Jan Kara, John Fastabend, Martin KaFai Lau, Yonghong Song,
Jiri Olsa, Eric Snowberg, Ondrej Mosnacek, linux-fsdevel,
linux-kernel, bpf, linux-security-module, linux-integrity,
selinux
In-Reply-To: <CAPhsuW5zRktottTujy_O1=8VkdJGDO71M3DVVM4ezffwT_dm+A@mail.gmail.com>
On Tue, May 5, 2026 at 5:00 AM Song Liu <song@kernel.org> wrote:
> On Tue, May 5, 2026 at 4:02 AM Paul Moore <paul@paul-moore.com> wrote:
> > On Mon, May 4, 2026 at 7:09 PM Song Liu <song@kernel.org> wrote:
> > > On Tue, May 5, 2026 at 12:42 AM Paul Moore <paul@paul-moore.com> wrote:
> > > [...]
> > > > > > Perhaps I'm simply not seeing it, but is there a check to ensure that
> > > > > > there is only one BPF LSM calling into security_inode_init_security()
> > > > > > at any given time? With the BPF LSM only reserving a single xattr
> > > > > > slot, multiple loaded BPF LSM programs providing
> > > > > > security_inode_init_security() callbacks will be a problem.
> > > > >
> > > > > I don't think there is such a check. Also, a single BPF LSM function
> > > > > may call the kfunc multiple times, which is also problematic.
> > > > >
> > > > > I think we will need to make the default bigger, and also introduce
> > > > > some realloc mechanism for the worst case scenario. This should
> > > > > work, but the code might be a bit messy.
> > > >
> > > > Thanks for the clarification, that is what I was afraid of when
> > > > looking at the code, but I was hoping I was just missing it.
> > > >
> > > > Increasing the default is an option, but I don't think we want to
> > > > support a dynamic reallocation scheme for the xattr slots, that will
> > > > likely get extremely messy with synchronization between the LSM
> > > > framework and BPF LSM hook registrations as well as special code to
> > > > handle inodes with lifetimes that are disjoint from the BPF LSM
> > > > programs ... I suppose there may be a way to do it, but it will surely
> > > > be ugly and come at a cost.
> > >
> > > BPF trampoline already handles all the synchronizations, such as
> > > add hook, remove hook, etc. properly. So this is not that hard.
> >
> > How do you plan to handle the issue of disjoint lifetimes?
> >
> > > All we really need is to allocate a new array, copy pointers, and free
> > > the old array. And we only really need this in the worst case
> > > scenarios.
> >
> > Oh, is that all? :D
> >
> > Keep in mind that the code must also handle arbitrary ordering of
> > LSMs; in other words, you must handle a BPF LSM that isn't at the end
> > of the LSM order. While a BPF LSM at the end of the LSM list is the
> > most common, and recommended ordering for the vast majority of users,
> > we've been working to make the ordering as generalized as possible.
>
> All the BPF LSM hooks are called together, so it should be fine.
> Maybe I missed some corner cases.
I was thinking about the LSM framework as a whole, not just the
potential for multiple BPF programs attached to the BPF LSM.
> Either way, I agree with David that we don't need too many xattrs.
> Since BPF LSM is reserved to the privileged users only, it is safe
> to put a reasonable limit, say 4 or 8, and do not handle the realloc.
> If the admin would like to brick a system with BPF LSM, there are
> many other ways to do it.
That is definitely the easier route. However, please add code to
ensure the number of attached BPF programs is limited to the number of
requested slots.
--
paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 0/3] initalise ff-a after finalising pKVM
From: Yeoreum Yun @ 2026-05-05 11:33 UTC (permalink / raw)
To: Ben Horgan
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,
sudeep.holla
In-Reply-To: <9dd2b09b-cfb1-40e5-9fdd-1e004ad784c0@arm.com>
> Hi Levi,
>
> On 5/5/26 12:16, Yeoreum Yun wrote:
> >> Hi Ben,
> >>
> >>> Hi Levi,
> >>>
> >>> On 5/5/26 10:54, Yeoreum Yun wrote:
> >>>> This patch is split out from the patchset [0] --
> >>>> fix FF-A call failure with pKVM when the FF-A driver is built-in,
> >>>> specifically the IMA-related part.
> >>>>
> >>>> 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.
> >>>>
> >>>> This patch is based on v7.1-rc2
> >>>>
> >>>> Question:
> >>>>
> >>>> FF-A initialisation can occur at late_initcall. Because it may be deferred,
> >>>> some FF-A requests cannot be serviced at that stage.
> >>>> A typical example is the EFI runtime variable service using DIRECT_MSG_REQ.
> >>>>
> >>>> Depending on the platform, the EFI runtime variable service runs with StandaloneMm
> >>>> and uses FF-A DIRECT_REQ. However, when pKVM is enabled, FF-A initialisation
> >>>> may be deferred to late_initcall. In this case, load_uefi_certs()
> >>>> can fail if it is invoked before the FF-A driver is initialised
> >>>> via deferred_probe_initcall().
> >>>>
> >>>> Moving load_uefi_certs() to late_initcall_sync, as in the third patch,
> >>>> seems not to have any problem since late_initcall and
> >>>> late_initcall_sync are both of do_basic_setup() and it's before loading
> >>>> init process. However, it is still unclear whether
> >>>> it would be better to allow DIRECT_MSG_REQ in kvm_host_ffa_handler()
> >>>
> >>> The spec doesn't allow this. Looking at DEN0077A 1.2 REL0:
> >>>
> >>> Section 13.2.2 says:
> >>>
> >>> "If they are compatible, it enables them to determine which Framework functionalities can be used. Hence, negotiation of
> >>> the version must happen before an invocation of any other FF-A ABI."
> >>>
> >>> and a bit further down
> >>>
> >>> "Once the caller invokes any FF-A ABI other than FFA_VERSION, the version negotiation phase is complete."
> >>>
> >>> I would have thought that an SP would only go into the waiting state once the version negotiation is done.
> >>
> >> I mean the negotiation between hypervisor and ff-a driver.
> >> actually the version negotiation is done with SPMC in
> >> hyp_ffa_init() but the negotiaion between hypervisor and ff-a driver
> >> just choose the lower version between version requested from ff-a driver
> >> and negotiated version with hypervisor and SPMC.
> >
> > Sorry. re-parse the word, not choose "re-negotiate" when
> > FF-A driver request lowever version.
> >
> >>
> >> So, the version negotiation is already done with SPMC
> >> but with FF-A driver with hypervisor is not yet.
> >> However, DIRECT_MSG_REQ has supported from v1.0
> >> In this situation, is there any reason not to send DIRECT_REQ_MSG?
> >
> > IOW, question is that some of ff-a request can be allowed
> > before version negotiation with FF-A driver but
> > using negotiated version via hyp_ffa_init() first or not.
>
> I don't think so. Isn't it more a continuation of the negotiation rather than a re-negotiation?
Might be. However, in the case I mentioned, I’m asking because
it’s somewhat unusual in that the FF-A request occurs without an “FF-A driver.”
If the FF-A request goes through the FF-A driver, then as you said,
it can reasonably be considered a continuation of the negotiation.
But in this case, I was wondering whether it would be acceptable to
introduce additional exception handling for situations
where an FF-A request occurs without the FF-A driver.
From that perspective, even if the FF-A request does not go through
the FF-A driver, it would ultimately still have to wait until
the FF-A driver initialization is complete.
So my question was whether certain operations could be handled
as exceptions in such cases.
Thanks.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [RFC PATCH 0/3] initalise ff-a after finalising pKVM
From: Ben Horgan @ 2026-05-05 11:24 UTC (permalink / raw)
To: Yeoreum Yun
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,
sudeep.holla
In-Reply-To: <afnRptWilWr7nABJ@e129823.arm.com>
Hi Levi,
On 5/5/26 12:16, Yeoreum Yun wrote:
>> Hi Ben,
>>
>>> Hi Levi,
>>>
>>> On 5/5/26 10:54, Yeoreum Yun wrote:
>>>> This patch is split out from the patchset [0] --
>>>> fix FF-A call failure with pKVM when the FF-A driver is built-in,
>>>> specifically the IMA-related part.
>>>>
>>>> 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.
>>>>
>>>> This patch is based on v7.1-rc2
>>>>
>>>> Question:
>>>>
>>>> FF-A initialisation can occur at late_initcall. Because it may be deferred,
>>>> some FF-A requests cannot be serviced at that stage.
>>>> A typical example is the EFI runtime variable service using DIRECT_MSG_REQ.
>>>>
>>>> Depending on the platform, the EFI runtime variable service runs with StandaloneMm
>>>> and uses FF-A DIRECT_REQ. However, when pKVM is enabled, FF-A initialisation
>>>> may be deferred to late_initcall. In this case, load_uefi_certs()
>>>> can fail if it is invoked before the FF-A driver is initialised
>>>> via deferred_probe_initcall().
>>>>
>>>> Moving load_uefi_certs() to late_initcall_sync, as in the third patch,
>>>> seems not to have any problem since late_initcall and
>>>> late_initcall_sync are both of do_basic_setup() and it's before loading
>>>> init process. However, it is still unclear whether
>>>> it would be better to allow DIRECT_MSG_REQ in kvm_host_ffa_handler()
>>>
>>> The spec doesn't allow this. Looking at DEN0077A 1.2 REL0:
>>>
>>> Section 13.2.2 says:
>>>
>>> "If they are compatible, it enables them to determine which Framework functionalities can be used. Hence, negotiation of
>>> the version must happen before an invocation of any other FF-A ABI."
>>>
>>> and a bit further down
>>>
>>> "Once the caller invokes any FF-A ABI other than FFA_VERSION, the version negotiation phase is complete."
>>>
>>> I would have thought that an SP would only go into the waiting state once the version negotiation is done.
>>
>> I mean the negotiation between hypervisor and ff-a driver.
>> actually the version negotiation is done with SPMC in
>> hyp_ffa_init() but the negotiaion between hypervisor and ff-a driver
>> just choose the lower version between version requested from ff-a driver
>> and negotiated version with hypervisor and SPMC.
>
> Sorry. re-parse the word, not choose "re-negotiate" when
> FF-A driver request lowever version.
>
>>
>> So, the version negotiation is already done with SPMC
>> but with FF-A driver with hypervisor is not yet.
>> However, DIRECT_MSG_REQ has supported from v1.0
>> In this situation, is there any reason not to send DIRECT_REQ_MSG?
>
> IOW, question is that some of ff-a request can be allowed
> before version negotiation with FF-A driver but
> using negotiated version via hyp_ffa_init() first or not.
I don't think so. Isn't it more a continuation of the negotiation rather than a re-negotiation?
Thanks,
Ben
>
> [...]
>
> Thanks.
>
^ permalink raw reply
* Re: [RFC PATCH 0/3] initalise ff-a after finalising pKVM
From: Yeoreum Yun @ 2026-05-05 11:16 UTC (permalink / raw)
To: Ben Horgan
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,
sudeep.holla
In-Reply-To: <afnLpG4osopTzpip@e129823.arm.com>
> Hi Ben,
>
> > Hi Levi,
> >
> > On 5/5/26 10:54, Yeoreum Yun wrote:
> > > This patch is split out from the patchset [0] --
> > > fix FF-A call failure with pKVM when the FF-A driver is built-in,
> > > specifically the IMA-related part.
> > >
> > > 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.
> > >
> > > This patch is based on v7.1-rc2
> > >
> > > Question:
> > >
> > > FF-A initialisation can occur at late_initcall. Because it may be deferred,
> > > some FF-A requests cannot be serviced at that stage.
> > > A typical example is the EFI runtime variable service using DIRECT_MSG_REQ.
> > >
> > > Depending on the platform, the EFI runtime variable service runs with StandaloneMm
> > > and uses FF-A DIRECT_REQ. However, when pKVM is enabled, FF-A initialisation
> > > may be deferred to late_initcall. In this case, load_uefi_certs()
> > > can fail if it is invoked before the FF-A driver is initialised
> > > via deferred_probe_initcall().
> > >
> > > Moving load_uefi_certs() to late_initcall_sync, as in the third patch,
> > > seems not to have any problem since late_initcall and
> > > late_initcall_sync are both of do_basic_setup() and it's before loading
> > > init process. However, it is still unclear whether
> > > it would be better to allow DIRECT_MSG_REQ in kvm_host_ffa_handler()
> >
> > The spec doesn't allow this. Looking at DEN0077A 1.2 REL0:
> >
> > Section 13.2.2 says:
> >
> > "If they are compatible, it enables them to determine which Framework functionalities can be used. Hence, negotiation of
> > the version must happen before an invocation of any other FF-A ABI."
> >
> > and a bit further down
> >
> > "Once the caller invokes any FF-A ABI other than FFA_VERSION, the version negotiation phase is complete."
> >
> > I would have thought that an SP would only go into the waiting state once the version negotiation is done.
>
> I mean the negotiation between hypervisor and ff-a driver.
> actually the version negotiation is done with SPMC in
> hyp_ffa_init() but the negotiaion between hypervisor and ff-a driver
> just choose the lower version between version requested from ff-a driver
> and negotiated version with hypervisor and SPMC.
Sorry. re-parse the word, not choose "re-negotiate" when
FF-A driver request lowever version.
>
> So, the version negotiation is already done with SPMC
> but with FF-A driver with hypervisor is not yet.
> However, DIRECT_MSG_REQ has supported from v1.0
> In this situation, is there any reason not to send DIRECT_REQ_MSG?
IOW, question is that some of ff-a request can be allowed
before version negotiation with FF-A driver but
using negotiated version via hyp_ffa_init() first or not.
[...]
Thanks.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [RFC PATCH 0/3] initalise ff-a after finalising pKVM
From: Yeoreum Yun @ 2026-05-05 10:51 UTC (permalink / raw)
To: Ben Horgan
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,
sudeep.holla
In-Reply-To: <8942c12e-6315-493e-98c5-d55f4e6341f4@arm.com>
Hi Ben,
> Hi Levi,
>
> On 5/5/26 10:54, Yeoreum Yun wrote:
> > This patch is split out from the patchset [0] --
> > fix FF-A call failure with pKVM when the FF-A driver is built-in,
> > specifically the IMA-related part.
> >
> > 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.
> >
> > This patch is based on v7.1-rc2
> >
> > Question:
> >
> > FF-A initialisation can occur at late_initcall. Because it may be deferred,
> > some FF-A requests cannot be serviced at that stage.
> > A typical example is the EFI runtime variable service using DIRECT_MSG_REQ.
> >
> > Depending on the platform, the EFI runtime variable service runs with StandaloneMm
> > and uses FF-A DIRECT_REQ. However, when pKVM is enabled, FF-A initialisation
> > may be deferred to late_initcall. In this case, load_uefi_certs()
> > can fail if it is invoked before the FF-A driver is initialised
> > via deferred_probe_initcall().
> >
> > Moving load_uefi_certs() to late_initcall_sync, as in the third patch,
> > seems not to have any problem since late_initcall and
> > late_initcall_sync are both of do_basic_setup() and it's before loading
> > init process. However, it is still unclear whether
> > it would be better to allow DIRECT_MSG_REQ in kvm_host_ffa_handler()
>
> The spec doesn't allow this. Looking at DEN0077A 1.2 REL0:
>
> Section 13.2.2 says:
>
> "If they are compatible, it enables them to determine which Framework functionalities can be used. Hence, negotiation of
> the version must happen before an invocation of any other FF-A ABI."
>
> and a bit further down
>
> "Once the caller invokes any FF-A ABI other than FFA_VERSION, the version negotiation phase is complete."
>
> I would have thought that an SP would only go into the waiting state once the version negotiation is done.
I mean the negotiation between hypervisor and ff-a driver.
actually the version negotiation is done with SPMC in
hyp_ffa_init() but the negotiaion between hypervisor and ff-a driver
just choose the lower version between version requested from ff-a driver
and negotiated version with hypervisor and SPMC.
So, the version negotiation is already done with SPMC
but with FF-A driver with hypervisor is not yet.
However, DIRECT_MSG_REQ has supported from v1.0
In this situation, is there any reason not to send DIRECT_REQ_MSG?
>
> > even before FF-A version negotiation since handler’s purpose seems to hook
> > certain memory operations, and DIRECT_MSG_REQ has been available
> > since FF-A specification v1.0.
> >
> > Any feedback or alternative suggestions would be appreciated!
> >
> > Link: https://lore.kernel.org/all/20260422162449.1814615-1-yeoreum.yun@arm.com/ [0]
> >
> > Yeoreum Yun (3):
> > arm64: KVM: defer kvm_init() to finalise_pkvm() when pKVM is enabled
> > firmware: arm_ffa: initialise ff-a after finalising pKVM
> > initialisation
> > security: integrity: call load_uefi_certs() at late_initcall_sync
> >
> > arch/arm64/kvm/arm.c | 8 +-
> > arch/arm64/kvm/pkvm.c | 15 ++-
> > drivers/firmware/arm_ffa/bus.c | 125 +++++++++++++++++-
> > drivers/firmware/arm_ffa/common.h | 13 +-
> > drivers/firmware/arm_ffa/driver.c | 21 ++-
> > drivers/firmware/arm_ffa/smccc.c | 2 +-
> > security/integrity/platform_certs/load_uefi.c | 2 +-
> > 7 files changed, 166 insertions(+), 20 deletions(-)
> >
> >
> > base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
>
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [RFC PATCH 0/3] initalise ff-a after finalising pKVM
From: Ben Horgan @ 2026-05-05 10:45 UTC (permalink / raw)
To: Yeoreum Yun, linux-integrity, keyrings, linux-security-module,
linux-kernel, linux-arm-kernel, kvmarm
Cc: jarkko, zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg,
paul, jmorris, serge, maz, oupton, joey.gouly, suzuki.poulose,
yuzenghui, catalin.marinas, will, sudeep.holla
In-Reply-To: <20260505095409.1948371-1-yeoreum.yun@arm.com>
Hi Levi,
On 5/5/26 10:54, Yeoreum Yun wrote:
> This patch is split out from the patchset [0] --
> fix FF-A call failure with pKVM when the FF-A driver is built-in,
> specifically the IMA-related part.
>
> 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.
>
> This patch is based on v7.1-rc2
>
> Question:
>
> FF-A initialisation can occur at late_initcall. Because it may be deferred,
> some FF-A requests cannot be serviced at that stage.
> A typical example is the EFI runtime variable service using DIRECT_MSG_REQ.
>
> Depending on the platform, the EFI runtime variable service runs with StandaloneMm
> and uses FF-A DIRECT_REQ. However, when pKVM is enabled, FF-A initialisation
> may be deferred to late_initcall. In this case, load_uefi_certs()
> can fail if it is invoked before the FF-A driver is initialised
> via deferred_probe_initcall().
>
> Moving load_uefi_certs() to late_initcall_sync, as in the third patch,
> seems not to have any problem since late_initcall and
> late_initcall_sync are both of do_basic_setup() and it's before loading
> init process. However, it is still unclear whether
> it would be better to allow DIRECT_MSG_REQ in kvm_host_ffa_handler()
The spec doesn't allow this. Looking at DEN0077A 1.2 REL0:
Section 13.2.2 says:
"If they are compatible, it enables them to determine which Framework functionalities can be used. Hence, negotiation of
the version must happen before an invocation of any other FF-A ABI."
and a bit further down
"Once the caller invokes any FF-A ABI other than FFA_VERSION, the version negotiation phase is complete."
I would have thought that an SP would only go into the waiting state once the version negotiation is done.
Thanks,
Ben
> even before FF-A version negotiation since handler’s purpose seems to hook
> certain memory operations, and DIRECT_MSG_REQ has been available
> since FF-A specification v1.0.
>
> Any feedback or alternative suggestions would be appreciated!
>
> Link: https://lore.kernel.org/all/20260422162449.1814615-1-yeoreum.yun@arm.com/ [0]
>
> Yeoreum Yun (3):
> arm64: KVM: defer kvm_init() to finalise_pkvm() when pKVM is enabled
> firmware: arm_ffa: initialise ff-a after finalising pKVM
> initialisation
> security: integrity: call load_uefi_certs() at late_initcall_sync
>
> arch/arm64/kvm/arm.c | 8 +-
> arch/arm64/kvm/pkvm.c | 15 ++-
> drivers/firmware/arm_ffa/bus.c | 125 +++++++++++++++++-
> drivers/firmware/arm_ffa/common.h | 13 +-
> drivers/firmware/arm_ffa/driver.c | 21 ++-
> drivers/firmware/arm_ffa/smccc.c | 2 +-
> security/integrity/platform_certs/load_uefi.c | 2 +-
> 7 files changed, 166 insertions(+), 20 deletions(-)
>
>
> base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
^ permalink raw reply
* [RFC PATCH 3/3] security: integrity: call load_uefi_certs() at late_initcall_sync
From: Yeoreum Yun @ 2026-05-05 9:54 UTC (permalink / raw)
To: linux-integrity, keyrings, linux-security-module, linux-kernel,
linux-arm-kernel, kvmarm
Cc: jarkko, zohar, roberto.sassu, dmitry.kasatkin, eric.snowberg,
paul, jmorris, serge, maz, oupton, joey.gouly, suzuki.poulose,
yuzenghui, catalin.marinas, will, sudeep.holla, Yeoreum Yun
In-Reply-To: <20260505095409.1948371-1-yeoreum.yun@arm.com>
In the arm64 pKVM environment, all FF-A requests fail until the FF-A
driver is initialized, as the FF-A version is not negotiated with the
hypervisor beforehand.
When FF-A is built-in and pKVM is enabled, pKVM
finalises its initialization at the device_initcall_sync level,
while the FF-A driver is initialized later at the late_initcall stage
via deferred probe.
When the EFI variable service runs with StandaloneMm, it uses
FFA_DIRECT_MSG to access EFI variables. As a result,
load_uefi_certs() always fails in this environment.
To address this issue, defer load_uefi_certs() to the
late_initcall_sync level.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
security/integrity/platform_certs/load_uefi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
index c0d6948446c3..cc2b879df5b6 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -235,4 +235,4 @@ static int __init load_uefi_certs(void)
return rc;
}
-late_initcall(load_uefi_certs);
+late_initcall_sync(load_uefi_certs);
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ permalink raw reply related
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