[PATCH v2 0/2] fix failure of integration IMA with tpm_crb_ffa

[PATCH v2 0/2] fix failure of integration IMA with tpm_crb_ffa

[Yeoreum Yun]

To integrate a TPM device that uses CRB over FF-A with the IMA subsystem,
both the tpm_crb and tpm_crb_ffa drivers must be built as built-in
(i.e., ARM_FFA_TRANSPORT=y, CONFIG_TCG_CRB=y, and CONFIG_TCG_CRB_FFA=y),
because IMA itself is built-in and the TPM device must be probed
before ima_init() is invoked during IMA subsystem initialization.

To ensure this works correctly, the following initcalls must be executed in order:
	1.	ffa_init()
	2.	tpm_crb_ffa_driver_init()
	3.	crb_acpi_driver_init()

Unfortunately, the order of these device initcalls cannot be strictly controlled.
As a result:
	1.	ffa_init() may be called after tpm_crb_ffa_driver_init()
	2.	tpm_crb_ffa_driver_init() may be called after crb_acpi_driver_init()

For example, the following initcall sequence may occur:
  0000000000000888 l  .initcall6.init>  crb_acpi_driver_init
  000000000000088c l  .initcall6.init>  tpm_crb_ffa_driver_init
  0000000000000a9c l  .initcall6.init>  ffa_init

In this situation, the IMA subsystem fails to integrate with the TPM device
because the TPM was not available at the time ima_init() was called.
As a result, you may see the following message in the kernel log:

  | ima: No TPM chip found, activating TPM-bypass!

To resolve this issue:
  Patch #1: change the initcall level of ffa_init() to rootfs_initcall,
            so that the FF-A device is created before any FF-A drivers are loaded.

  Patch #2: call ffa_register() in tpm_crb_ffa_init() when it is built as built-in,
            ensuring that the Secure Partition used by tpm_crb_ffa
            is already registered when the TPM device is probed.

==============
Patch History
==============
  Since v1:
     - rewrite commit message.
     - https://lore.kernel.org/all/20250606105754.1202649-1-yeoreum.yun@arm.com/


Yeoreum Yun (2):
  firmware: arm_ffa: Change initcall level of ffa_init() to
    rootfs_initcall
  tpm: tpm_crb_ffa: maunally register tpm_crb_ffa driver when it's
    built-in

 drivers/char/tpm/tpm_crb_ffa.c    | 22 +++++++++++++++++-----
 drivers/firmware/arm_ffa/driver.c |  2 +-
 2 files changed, 18 insertions(+), 6 deletions(-)

--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

[PATCH v2 1/2] firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall

[Yeoreum Yun]

The Linux IMA (Integrity Measurement Architecture) subsystem used for secure
boot, file integrity, or remote attestation cannot be a loadable module
for few reasons listed below:

 o Boot-Time Integrity: IMA’s main role is to measure and appraise files
   before they are used. This includes measuring critical system files during
   early boot (e.g., init, init scripts, login binaries). If IMA were a module,
   it would be loaded too late to cover those.

 o TPM Dependency: IMA integrates tightly with the TPM to record measurements
   into PCRs. The TPM must be initialized early (ideally before init_ima()),
   which aligns with IMA being built-in.

 o Security Model: IMA is part of a Trusted Computing Base (TCB). Making it a
   module would weaken the security model, as a potentially compromised system
   could delay or tamper with its initialization.

IMA must be built-in to ensure it starts measuring from the earliest possible
point in boot which inturn implies TPM must be initialised and ready to use
before IMA.

To enable integration of tpm_event_log with the IMA subsystem, the TPM drivers
(tpm_crb and tpm_crb_ffa) also needs to be built-in. However with FF-A driver
also being initialised at device initcall level, it can lead to an
initialization order issue where:
 - crb_acpi_driver_init() may run before tpm_crb_ffa_driver()_init and ffa_init()
 - As a result, probing the TPM device via CRB over FFA is deferred
 - ima_init() (called as a late initcall) runs before deferred probe completes,
   IMA fails to find the TPM and logs the below error:

   |  ima: No TPM chip found, activating TPM-bypass!

Eventually it fails to generate boot_aggregate with PCR values.

Because of the above stated dependency, the ffa driver needs to initialised
before tpm_crb_ffa module to ensure IMA finds the TPM successfully when
present.

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
 drivers/firmware/arm_ffa/driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index fe55613a8ea9..1a690b8186df 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -2058,7 +2058,7 @@ static int __init ffa_init(void)
 	kfree(drv_info);
 	return ret;
 }
-module_init(ffa_init);
+rootfs_initcall(ffa_init);
 
 static void __exit ffa_exit(void)
 {
-- 
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

[PATCH v2 2/2] tpm: tpm_crb_ffa: manually register tpm_crb_ffa driver when it's built-in

[Yeoreum Yun]

To integrate tpm_event_log with IMA subsystem,
tpm_crb and tpm_crb_ffa driver should be built as built-in
(CONFIG_TCG_CRB=y && CONFIG_TCG_CRB_FFA=y) and
TPM device using CRB over FF-A should be probed
before ima_init() which is called as late_initcall.

However, we couldn't control the probing order between
crb_acpi_driver_init() and tpm_crb_ffa_driver_init() that's why
crb_acpi_driver_init() could be called before
tpm_crb_ffa_driver_init() when they're deployed like:

0000000000000888 l       .initcall6.init>-0000000000000000 crb_acpi_driver_init
000000000000088c l       .initcall6.init>-0000000000000000 tpm_crb_ffa_driver_init

In this situation, the TPM device is queued deferred probing
and it can be handled later ima_init() caled in init_ima().

000000000000012c l       .initcall7.init>-0000000000000000 init_ima
000000000000016c l       .initcall7.init>-0000000000000000 deferred_probe_initcall7

When this happen, IMA fails to generate boot_aggregate with
TPM's PCR values so it prints below message:

   | ima: No TPM chip found, activating TPM-bypass!

To resolve this issue, the tpm_crb_ffa_init() function
attempts to probe the tpm_crb_ffa device.
This ensures that the TPM device using CRB over FF-A can be
successfully probed even if crb_acpi_driver_init() is called first.

Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
 drivers/char/tpm/tpm_crb_ffa.c | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
index 4ead61f01299..2ef29b66fa5d 100644
--- a/drivers/char/tpm/tpm_crb_ffa.c
+++ b/drivers/char/tpm/tpm_crb_ffa.c
@@ -115,6 +115,7 @@ struct tpm_crb_ffa {
 };

 static struct tpm_crb_ffa *tpm_crb_ffa;
+static struct ffa_driver tpm_crb_ffa_driver;

 static int tpm_crb_ffa_to_linux_errno(int errno)
 {
@@ -168,13 +169,22 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
  */
 int tpm_crb_ffa_init(void)
 {
-	if (!tpm_crb_ffa)
-		return -ENOENT;
+	int ret = 0;

-	if (IS_ERR_VALUE(tpm_crb_ffa))
-		return -ENODEV;
+	if (IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
+		if (!tpm_crb_ffa)
+			ret = -ENOENT;

-	return 0;
+		if (IS_ERR_VALUE(tpm_crb_ffa))
+			ret = -ENODEV;
+
+		return ret;
+	}
+
+	ret = ffa_register(&tpm_crb_ffa_driver);
+	BUG_ON(!ret && !tpm_crb_ffa);
+
+	return ret;
 }
 EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);

@@ -369,7 +379,9 @@ static struct ffa_driver tpm_crb_ffa_driver = {
 	.id_table = tpm_crb_ffa_device_id,
 };

+#ifdef MODULE
 module_ffa_driver(tpm_crb_ffa_driver);
+#endif

 MODULE_AUTHOR("Arm");
 MODULE_DESCRIPTION("TPM CRB FFA driver");
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

Re: [PATCH v2 0/2] fix failure of integration IMA with tpm_crb_ffa

[Jarkko Sakkinen]

On Tue, Jun 10, 2025 at 07:03:32AM +0100, Yeoreum Yun wrote:
> To integrate a TPM device that uses CRB over FF-A with the IMA subsystem,
> both the tpm_crb and tpm_crb_ffa drivers must be built as built-in
> (i.e., ARM_FFA_TRANSPORT=y, CONFIG_TCG_CRB=y, and CONFIG_TCG_CRB_FFA=y),
> because IMA itself is built-in and the TPM device must be probed
> before ima_init() is invoked during IMA subsystem initialization.

The description of the problem and motivation to solve it should be
first; not the actions taken.

> 
> To ensure this works correctly, the following initcalls must be executed in order:
> 	1.	ffa_init()
> 	2.	tpm_crb_ffa_driver_init()
> 	3.	crb_acpi_driver_init()
> 
> Unfortunately, the order of these device initcalls cannot be strictly controlled.
> As a result:
> 	1.	ffa_init() may be called after tpm_crb_ffa_driver_init()
> 	2.	tpm_crb_ffa_driver_init() may be called after crb_acpi_driver_init()
> 
> For example, the following initcall sequence may occur:
>   0000000000000888 l  .initcall6.init>  crb_acpi_driver_init
>   000000000000088c l  .initcall6.init>  tpm_crb_ffa_driver_init

This symbol does not exist.

>   0000000000000a9c l  .initcall6.init>  ffa_init
> 
> In this situation, the IMA subsystem fails to integrate with the TPM device
> because the TPM was not available at the time ima_init() was called.
> As a result, you may see the following message in the kernel log:
> 
>   | ima: No TPM chip found, activating TPM-bypass!

TPM initializes before IMA, so there should not be a problem.

BR, Jarkko

Re: [PATCH v2 0/2] fix failure of integration IMA with tpm_crb_ffa

[Yeoreum Yun]

Hi Jarkko,

> On Tue, Jun 10, 2025 at 07:03:32AM +0100, Yeoreum Yun wrote:
> > To integrate a TPM device that uses CRB over FF-A with the IMA subsystem,
> > both the tpm_crb and tpm_crb_ffa drivers must be built as built-in
> > (i.e., ARM_FFA_TRANSPORT=y, CONFIG_TCG_CRB=y, and CONFIG_TCG_CRB_FFA=y),
> > because IMA itself is built-in and the TPM device must be probed
> > before ima_init() is invoked during IMA subsystem initialization.
>
> The description of the problem and motivation to solve it should be
> first; not the actions taken.

Okay. I'll describe the problem first.

>
> >
> > To ensure this works correctly, the following initcalls must be executed in order:
> > 	1.	ffa_init()
> > 	2.	tpm_crb_ffa_driver_init()
> > 	3.	crb_acpi_driver_init()
> >
> > Unfortunately, the order of these device initcalls cannot be strictly controlled.
> > As a result:
> > 	1.	ffa_init() may be called after tpm_crb_ffa_driver_init()
> > 	2.	tpm_crb_ffa_driver_init() may be called after crb_acpi_driver_init()
> >
> > For example, the following initcall sequence may occur:
> >   0000000000000888 l  .initcall6.init>  crb_acpi_driver_init
> >   000000000000088c l  .initcall6.init>  tpm_crb_ffa_driver_init
>
> This symbol does not exist.

I don't know you said "This symbol does not exit".
When CONFIG_TCG=CRB=y, CONFIG_TCG_CRB_FFA=y and ARM_FFA_TRANSPORT=y,
above symbols exist.

crb_acpi_driver_init() generated by
  module_acpi_driver(crb_acpi_driver);
in tpm_crb.c

and tpm_crb_ffa_driver_init() generated by
  module_ffa_driver(tpm_crb_ffa_driver);
in tpm_crb_ffa.c so you can get the above symbols:

$ llvm-readelf-21 --symbols vmlinux | grep crb | grep init
171332: ffff80008203ef08    56 FUNC    LOCAL  DEFAULT    19 crb_acpi_driver_init
...
370077: ffff800080d650d8    92 FUNC    GLOBAL DEFAULT     2 tpm_crb_ffa_init

>
> >   0000000000000a9c l  .initcall6.init>  ffa_init
> >
> > In this situation, the IMA subsystem fails to integrate with the TPM device
> > because the TPM was not available at the time ima_init() was called.
> > As a result, you may see the following message in the kernel log:
> >
> >   | ima: No TPM chip found, activating TPM-bypass!
>
> TPM initializes before IMA, so there should not be a problem.

If you see my commit message it describes the situation why this happen.
when crb_acpi_driver_init() is called but before tpm_crb_ffa_init() is
called, the secure partition doesn't probe. so crb_acpi_driver_init()
would be failed wiith -EPROBE.

In this situation, init_ima() which call ima_init() can be called first.
NOTE, init_ima() is deployed in late_initcall and
the "deferred_probe device" is tried again in
deferred_probe late initcall.
However, even the deferred_probe can be call later then init_ima().

000000000000012c l       .initcall7.init>-------0000000000000000 init_ima
000000000000016c l       .initcall7.init>-------0000000000000000 deferred_probe_initcall7

That's why init_ima() is failed to init with TPM when It is deffered.

Would you let me know why you said it's not a problem?

--
Sincerely,
Yeoreum Yun

Re: [PATCH v2 0/2] fix failure of integration IMA with tpm_crb_ffa

[Jarkko Sakkinen]

On Tue, Jun 10, 2025 at 02:18:29PM +0100, Yeoreum Yun wrote:
>   module_ffa_driver(tpm_crb_ffa_driver);

Oops, I missed this statement. Sorry, my bad.

> 
> >
> > >   0000000000000a9c l  .initcall6.init>  ffa_init
> > >
> > > In this situation, the IMA subsystem fails to integrate with the TPM device
> > > because the TPM was not available at the time ima_init() was called.
> > > As a result, you may see the following message in the kernel log:
> > >
> > >   | ima: No TPM chip found, activating TPM-bypass!
> >
> > TPM initializes before IMA, so there should not be a problem.
> 
> If you see my commit message it describes the situation why this happen.
> when crb_acpi_driver_init() is called but before tpm_crb_ffa_init() is
> called, the secure partition doesn't probe. so crb_acpi_driver_init()
> would be failed wiith -EPROBE.

What is "secure partition" and why it doesn't probe at the time of
crb_acpi_driver_init()?

> 
> In this situation, init_ima() which call ima_init() can be called first.
> NOTE, init_ima() is deployed in late_initcall and
> the "deferred_probe device" is tried again in
> deferred_probe late initcall.
> However, even the deferred_probe can be call later then init_ima().
> 
> 000000000000012c l       .initcall7.init>-------0000000000000000 init_ima
> 000000000000016c l       .initcall7.init>-------0000000000000000 deferred_probe_initcall7
> 
> That's why init_ima() is failed to init with TPM when It is deffered.
> 
> Would you let me know why you said it's not a problem?

What has deferred_probe_initcall has to do with this? Not actually
asking just pointing out stuff that you should open up.

> 
> --
> Sincerely,
> Yeoreum Yun

BR, Jarkko

Re: [PATCH v2 0/2] fix failure of integration IMA with tpm_crb_ffa

[Yeoreum Yun]

Hi Jarkko,

[...]
>
> >
> > >
> > > >   0000000000000a9c l  .initcall6.init>  ffa_init
> > > >
> > > > In this situation, the IMA subsystem fails to integrate with the TPM device
> > > > because the TPM was not available at the time ima_init() was called.
> > > > As a result, you may see the following message in the kernel log:
> > > >
> > > >   | ima: No TPM chip found, activating TPM-bypass!
> > >
> > > TPM initializes before IMA, so there should not be a problem.
> >
> > If you see my commit message it describes the situation why this happen.
> > when crb_acpi_driver_init() is called but before tpm_crb_ffa_init() is
> > called, the secure partition doesn't probe. so crb_acpi_driver_init()
> > would be failed wiith -EPROBE.
>
> What is "secure partition" and why it doesn't probe at the time of
> crb_acpi_driver_init()?

secure partition is a secure service provider and among this service,
there is TPM services using CRB over FF-A.

This service is represented with "ffa_device" generated in
ffa_init() in arm_ffa driver.

tpm_crb_ffa driver attaches to this device and provide the interface to
tpm_crb for communicating TPM device via CRB over FF-A.

tpm_crb can communicate this TPM device after this ffa_device is probed.
Therefore to probe the tpm_crb which uses CRB over FF-A:
  1. related ffa_device should be registered which is done via ffa_init().
  2. tpm_crb_driver success to probe above device which is done
     via tpm_crb_ffa_init().
  3. tpm_crb which uses CRB over FF-A can be probed above this is
     probed. -- See crb_acpi_add() and tpm_crb_ffa_init().

Unfortunately, when they're built as built-in,
ffa_init(), tpm_crb_ffa_init() and crb_acpi_driver_init() are deployed in
device_initcall. So, If crb_acpi_driver_init() is called,
If there is no ffa_device or ffa_device isn't probe yet,
It returns -EPROBE in crb_acpi_driver_init() so it's delayed to probe
to deferred_probe_initcall.


A secure partition is a secure service provider.
Among the services it offers, one includes TPM services that
use the CRB interface over FF-A (Firmware Framework for Arm).

This service is represented by an ffa_device, which is created
during the ffa_init() routine in the arm_ffa driver.
The tpm_crb_ffa driver attaches to this ffa_device and
provides an interface to the tpm_crb driver,
enabling communication with the TPM device via CRB over FF-A.

The tpm_crb driver can only communicate with the TPM device
once the corresponding ffa_device has been probed.

Therefore, for a tpm_crb driver that uses CRB over FF-A to be probed properly:
  1. The associated ffa_device must be registered, which happens via ffa_init().
  2. The tpm_crb_driver must successfully probe this device through tpm_crb_ffa_init().
  3. Once that is complete, the tpm_crb driver using CRB over FF-A can then be probed.
     See crb_acpi_add() and tpm_crb_ffa_init() for details.

Unfortunately, when these components are built as built-in drivers,
the functions ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
all executed during the device_initcall phase.
As a result, if crb_acpi_driver_init() is called before the ffa_device exists or
has been probed, it returns -EPROBE_DEFER,
causing the probe to be deferred and retried later
during the deferred_probe_initcall phase.

>
> >
> > In this situation, init_ima() which call ima_init() can be called first.
> > NOTE, init_ima() is deployed in late_initcall and
> > the "deferred_probe device" is tried again in
> > deferred_probe late initcall.
> > However, even the deferred_probe can be call later then init_ima().
> >
> > 000000000000012c l       .initcall7.init>-------0000000000000000 init_ima
> > 000000000000016c l       .initcall7.init>-------0000000000000000 deferred_probe_initcall7
> >
> > That's why init_ima() is failed to init with TPM when It is deffered.
> >
> > Would you let me know why you said it's not a problem?
>
> What has deferred_probe_initcall has to do with this? Not actually
> asking just pointing out stuff that you should open up.

What I want to point out is that
If the TPM device is failed to init in its initcall, and defered
the IMA can be failed to find out the TPM device
since init_ima() is called first before deferred_probe_initcall.

--
Sincerely,
Yeoreum Yun

Re: [PATCH v2 0/2] fix failure of integration IMA with tpm_crb_ffa

[Jarkko Sakkinen]

On Tue, Jun 10, 2025 at 03:38:27PM +0100, Yeoreum Yun wrote:
> Unfortunately, when these components are built as built-in drivers,
> the functions ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> all executed during the device_initcall phase.
> As a result, if crb_acpi_driver_init() is called before the ffa_device exists or
> has been probed, it returns -EPROBE_DEFER,

Please mention exactly this in the commit explicitly and then it should
be in detail enough.

> causing the probe to be deferred and retried later
> during the deferred_probe_initcall phase.

OK, if ffa_init() is leveled up in the initcall hierarchy, shouldn't
that be enough as long as ko's can be found from initramfs?

BR, Jarkko

Re: [PATCH v2 0/2] fix failure of integration IMA with tpm_crb_ffa

[Yeoreum Yun]

Hi Jarkko,

> > Unfortunately, when these components are built as built-in drivers,
> > the functions ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > all executed during the device_initcall phase.
> > As a result, if crb_acpi_driver_init() is called before the ffa_device exists or
> > has been probed, it returns -EPROBE_DEFER,
>
> Please mention exactly this in the commit explicitly and then it should
> be in detail enough.

Okay. I'll add this in the next round in cover letter.

>
> > causing the probe to be deferred and retried later
> > during the deferred_probe_initcall phase.
>
> OK, if ffa_init() is leveled up in the initcall hierarchy, shouldn't
> that be enough as long as ko's can be found from initramfs?

As you mentioned, this is handled in Patch #1.
However, although ffa_init() is called first,
unless tpm_crb_ffa_init() is also invoked,
crb_acpi_driver_init() will fail with -EPROBE_DEFER.

Please note that IMA is always built-in and cannot be built as a module.
To generate boot_aggregate with TPM PCR values from 0 to 7,
the TPM-related modules must also be built-in and
properly initialized before init_ima(), which internally calls ima_init().

To ensure this, Patch #2 adds a routine to probe
the ffa_device() in tpm_crb_ffa_init().
This allows crb_acpi_driver_init() to successfully complete even if
it is called first, because tpm_crb_ffa_init() triggers
probing of the ffa_device via ffa_register() beforehand.

Thanks.
--
Sincerely,
Yeoreum Yun

Re: [PATCH v2 0/2] fix failure of integration IMA with tpm_crb_ffa

[Jarkko Sakkinen]

On Tue, Jun 10, 2025 at 04:22:04PM +0100, Yeoreum Yun wrote:
> > OK, if ffa_init() is leveled up in the initcall hierarchy, shouldn't
> > that be enough as long as ko's can be found from initramfs?
> 
> As you mentioned, this is handled in Patch #1.
> However, although ffa_init() is called first,
> unless tpm_crb_ffa_init() is also invoked,
> crb_acpi_driver_init() will fail with -EPROBE_DEFER.
> 
> Please note that IMA is always built-in and cannot be built as a module.

Sure but if one needs IMA, then tpm_crb_ffa can be compiled as built-in
with zero code changes.

BR, Jarkko

Re: [PATCH v2 0/2] fix failure of integration IMA with tpm_crb_ffa

[Yeoreum Yun]

Hi Jarkko,

> On Tue, Jun 10, 2025 at 04:22:04PM +0100, Yeoreum Yun wrote:
> > > OK, if ffa_init() is leveled up in the initcall hierarchy, shouldn't
> > > that be enough as long as ko's can be found from initramfs?
> >
> > As you mentioned, this is handled in Patch #1.
> > However, although ffa_init() is called first,
> > unless tpm_crb_ffa_init() is also invoked,
> > crb_acpi_driver_init() will fail with -EPROBE_DEFER.
> >
> > Please note that IMA is always built-in and cannot be built as a module.
>
> Sure but if one needs IMA, then tpm_crb_ffa can be compiled as built-in
> with zero code changes.

All of my describtion based on all things are built as "built-in".
in case of ffa_init() changes the init level to root_initcall,
so, the ffa_device will be produced first before the trial of TPM probe.

Note that tpm_crb_ffa_init() which is the "ffa_driver" is called in
device_initcall level. I mean

    ffa_init() -> arm_ffa -> root_initcall
    tpm_crb_ffa_init() -> device_initcall
    crb_acpi_driver_init() -> device_initcall

therefore, "crb_acpi_driver_init()" can be call first before
tpm_crb_ffa_init() since they're deployed in device_initcall.
If this happen, "crb_acpi_driver_init()" failed with -EPROBE_DEFER.

That's why this patch is required to probe "tpm_crb_ffa" when
crb_acpi_driver_init() called to complete the TPM device probe before
IMA subsystem initailization.

Thanks.

--
Sincerely,
Yeoreum Yun

Re: [PATCH v2 0/2] fix failure of integration IMA with tpm_crb_ffa

[Jarkko Sakkinen]

On Wed, Jun 11, 2025 at 06:36:02PM +0100, Yeoreum Yun wrote:
> Hi Jarkko,
> 
> > On Tue, Jun 10, 2025 at 04:22:04PM +0100, Yeoreum Yun wrote:
> > > > OK, if ffa_init() is leveled up in the initcall hierarchy, shouldn't
> > > > that be enough as long as ko's can be found from initramfs?
> > >
> > > As you mentioned, this is handled in Patch #1.
> > > However, although ffa_init() is called first,
> > > unless tpm_crb_ffa_init() is also invoked,
> > > crb_acpi_driver_init() will fail with -EPROBE_DEFER.
> > >
> > > Please note that IMA is always built-in and cannot be built as a module.
> >
> > Sure but if one needs IMA, then tpm_crb_ffa can be compiled as built-in
> > with zero code changes.
> 
> All of my describtion based on all things are built as "built-in".
> in case of ffa_init() changes the init level to root_initcall,
> so, the ffa_device will be produced first before the trial of TPM probe.
> 
> Note that tpm_crb_ffa_init() which is the "ffa_driver" is called in
> device_initcall level. I mean
> 
>     ffa_init() -> arm_ffa -> root_initcall
>     tpm_crb_ffa_init() -> device_initcall
>     crb_acpi_driver_init() -> device_initcall
> 
> therefore, "crb_acpi_driver_init()" can be call first before
> tpm_crb_ffa_init() since they're deployed in device_initcall.
> If this happen, "crb_acpi_driver_init()" failed with -EPROBE_DEFER.
> 
> That's why this patch is required to probe "tpm_crb_ffa" when
> crb_acpi_driver_init() called to complete the TPM device probe before
> IMA subsystem initailization.

Yep, and you sort it out by not compiling it as a module.

+	ret = ffa_register(&tpm_crb_ffa_driver);
+	BUG_ON(!ret && !tpm_crb_ffa);

These lines struck me in your patch. The commit message has nothing
about ffa_register().

Also, please remove BUG_ON(). That said, I don't think 2/2 is needed.

> 
> Thanks.
> 
> --
> Sincerely,
> Yeoreum Yun


BR, Jarkko

Re: [PATCH v2 0/2] fix failure of integration IMA with tpm_crb_ffa

[Yeoreum Yun]

Hi Jarkko,

[...]
> Yep, and you sort it out by not compiling it as a module.
>
> +	ret = ffa_register(&tpm_crb_ffa_driver);
> +	BUG_ON(!ret && !tpm_crb_ffa);
>
> These lines struck me in your patch. The commit message has nothing
> about ffa_register().


Sorry. I think I miss the description for this detail.

This is core of this patch.
So, in patch #1, by chaning the ffa_init() to rootfs_initcall,
it ensures the generation of "tpm_crb_ffa device" is created before
crb_acpi_driver_init() but "tpm_crb_ffa device" isn't probe yet since
the "tpm_crb_ffa driver" isn't yet registered which is registered by
"tpm_crb_ffa_init()".

Therefore, this patch does that when crb_acpi_driver_init() is called first,
tpm_crb_init() registers "tpm_crb_ffa driver" via "ffa_register()"
to trigger probing of "tpm_crb_ffa device" to initalize
the TPM device using CRB over FF-A.

>
> Also, please remove BUG_ON(). That said, I don't think 2/2 is needed.

Okay. I'll replace it with error message.

Thanks.

--
Sincerely,
Yeoreum Yun