[PATCH v4 0/2] generate boot_aggregate log in IMA with TPM using CRB over FF-A

[PATCH v4 0/2] generate boot_aggregate log in IMA with TPM using CRB over FF-A

[Yeoreum Yun]

To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
the TPM driver must be built as built-in and
must be probed before the IMA subsystem is initialized.

However, when the TPM device operates over the FF-A protocol using the CRB interface,
probing fails and returns -EPROBE_DEFER if
the tpm_crb_ffa device — an FF-A device that provides the communication
interface to the tpm_crb driver — has not yet been probed.

To ensure the TPM device operating over the FF-A protocol with
the CRB interface is probed before IMA initialization,
the following conditions must be met:

   1. The corresponding ffa_device must be registered,
      which is done via ffa_init().

   2. The tpm_crb_driver must successfully probe this device via
      tpm_crb_ffa_init().

   3. The tpm_crb driver using CRB over FF-A can then
      be probed successfully. (See crb_acpi_add() and
      tpm_crb_ffa_init() for reference.)

Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
all registered with device_initcall, which means crb_acpi_driver_init() may
be invoked before ffa_init() and tpm_crb_ffa_init() are completed.

When this occurs, probing the TPM device is deferred.
However, the deferred probe may happen after
the IMA subsystem has already been initialized,
since IMA initialization is performed during late_initcall,
and deferred probing is handled asynchronously via a workqueue.

This patch addresses the issue by ensuring timely probing of
the tpm_crb_ffa device during TPM initialization:

  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: When built as built-in, call ffa_register() within tpm_crb_ffa_init()
            to ensure the Secure Partition used by tpm_crb_ffa is already registered
            before the TPM device is probed.

==============
Patch History
==============
  Since v3:
     - remove BUG_ON.
     - https://lore.kernel.org/all/20250611112448.17751-1-yeoreum.yun@arm.com/

  Since v2:
     - rewrite cover letter and commit message:
     - https://lore.kernel.org/all/aEgwpXXftXW6JNRy@e129823.arm.com/

  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: try to probe tpm_crb_ffa when it's built-in

 drivers/char/tpm/tpm_crb_ffa.c    | 19 ++++++++++++++++---
 drivers/firmware/arm_ffa/driver.c |  2 +-
 2 files changed, 17 insertions(+), 4 deletions(-)

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

[PATCH v4 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 v4 2/2] tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in

[Yeoreum Yun]

To generate the boot_aggregate log in the IMA subsystem using TPM PCR values,
the TPM driver must be built as built-in and must be probed before
the IMA subsystem is initialized.

However, when the TPM device operates over the FF-A protocol using the CRB interface,
probing fails and returns -EPROBE_DEFER
if the tpm_crb_ffa device — an FF-A device that provides
the communication interface to the tpm_crb driver — has not yet been probed.

This issue occurs because both crb_acpi_driver_init() and
tpm_crb_ffa_driver_init() are registered with device_initcall.
As a result, crb_acpi_driver_init() may be invoked before
tpm_crb_ffa_driver_init(), which is responsible for probing the tpm_crb_ffa device.

When this happens, IMA fails to detect the TPM device and
logs the following message:

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

Consequently, it cannot generate the boot_aggregate log with
the PCR values provided by the TPM.

To resolve this issue, the tpm_crb_ffa_init() function explicitly attempts to
probe the tpm_crb_ffa by register tpm_crb_ffa driver so that
when tpm_crb_ffa device is created before tpm_crb_ffa_init(),
probe the tpm_crb_ffa device in tpm_crb_ffa_init() to finish probe the
TPM device completely.

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 | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
index 4ead61f01299..462fcf610020 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,23 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
  */
 int tpm_crb_ffa_init(void)
 {
+	int ret = 0;
+
+	if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
+		ret = ffa_register(&tpm_crb_ffa_driver);
+		if (ret) {
+			tpm_crb_ffa = ERR_PTR(-ENODEV);
+			return ret;
+		}
+	}
+
 	if (!tpm_crb_ffa)
-		return -ENOENT;
+		ret = -ENOENT;
 
 	if (IS_ERR_VALUE(tpm_crb_ffa))
-		return -ENODEV;
+		ret = -ENODEV;
 
-	return 0;
+	return ret;
 }
 EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
 
@@ -369,7 +380,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 v4 1/2] firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall

[Mimi Zohar]

On Wed, 2025-06-18 at 11:23 +0100, Yeoreum Yun wrote:
> 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>

Thank you for the well written patch description.

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

LGTM as the driver is always builtin.

Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>

>  
>  static void __exit ffa_exit(void)
>  {

Re: [PATCH v4 2/2] tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in

[Mimi Zohar]

On Wed, 2025-06-18 at 11:23 +0100, Yeoreum Yun wrote:
> To generate the boot_aggregate log in the IMA subsystem using TPM PCR values,
> the TPM driver must be built as built-in and must be probed before
> the IMA subsystem is initialized.
> 
> However, when the TPM device operates over the FF-A protocol using the CRB interface,
> probing fails and returns -EPROBE_DEFER
> if the tpm_crb_ffa device — an FF-A device that provides
> the communication interface to the tpm_crb driver — has not yet been probed.
> 
> This issue occurs because both crb_acpi_driver_init() and
> tpm_crb_ffa_driver_init() are registered with device_initcall.
> As a result, crb_acpi_driver_init() may be invoked before
> tpm_crb_ffa_driver_init(), which is responsible for probing the tpm_crb_ffa device.
> 
> When this happens, IMA fails to detect the TPM device and
> logs the following message:
> 
>   | ima: No TPM chip found, activating TPM-bypass!
> 
> Consequently, it cannot generate the boot_aggregate log with
> the PCR values provided by the TPM.
> 
> To resolve this issue, the tpm_crb_ffa_init() function explicitly attempts to
> probe the tpm_crb_ffa by register tpm_crb_ffa driver so that
> when tpm_crb_ffa device is created before tpm_crb_ffa_init(),
> probe the tpm_crb_ffa device in tpm_crb_ffa_init() to finish probe the
> TPM device completely.
> 
> 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 | 19 ++++++++++++++++---
>  1 file changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
> index 4ead61f01299..462fcf610020 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,23 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
>   */
>  int tpm_crb_ffa_init(void)
>  {
> +	int ret = 0;
> +
> +	if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
> +		ret = ffa_register(&tpm_crb_ffa_driver);
> +		if (ret) {
> +			tpm_crb_ffa = ERR_PTR(-ENODEV);
> +			return ret;
> +		}
> +	}
> +
>  	if (!tpm_crb_ffa)
> -		return -ENOENT;
> +		ret = -ENOENT;
>  
>  	if (IS_ERR_VALUE(tpm_crb_ffa))
> -		return -ENODEV;
> +		ret = -ENODEV;
>  
> -	return 0;
> +	return ret;
>  }
>  EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
>  
> @@ -369,7 +380,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");

LGTM.  Using ifndef/ifdef MODULE is similar to how module_init() works for both
builtin and loadable kernel modules. Except module_init() is on the
device_initcall().

Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>

Re: [PATCH v4 0/2] generate boot_aggregate log in IMA with TPM using CRB over FF-A

[Jarkko Sakkinen]

On Wed, Jun 18, 2025 at 11:23:00AM +0100, Yeoreum Yun wrote:
> To ensure the TPM device operating over the FF-A protocol with
> the CRB interface is probed before IMA initialization,
> the following conditions must be met:
> 
>    1. The corresponding ffa_device must be registered,
>       which is done via ffa_init().
> 
>    2. The tpm_crb_driver must successfully probe this device via
>       tpm_crb_ffa_init().
> 
>    3. The tpm_crb driver using CRB over FF-A can then
>       be probed successfully. (See crb_acpi_add() and
>       tpm_crb_ffa_init() for reference.)
> 
> Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> all registered with device_initcall, which means crb_acpi_driver_init() may
> be invoked before ffa_init() and tpm_crb_ffa_init() are completed.

I get the ffa_init() part i.e, moving it earlier. However for
tpm_crb_ffa_init() and crb_acpi_driver_init(), modules.dep
takes care that they are loaded in order.

For IMA you will need the driver as built-in but that should
be handled via kernel config, not via code changes.

BR, Jarkko 

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

[Jarkko Sakkinen]

On Wed, Jun 18, 2025 at 11:23:01AM +0100, Yeoreum Yun wrote:
> 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}
> 

Acked-by: Jarkko Sakkinen <jarkko@kernel.org>

BR, Jarkko

Re: [PATCH v4 2/2] tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in

[Jarkko Sakkinen]

On Wed, Jun 18, 2025 at 11:23:02AM +0100, Yeoreum Yun wrote:
> To generate the boot_aggregate log in the IMA subsystem using TPM PCR values,
> the TPM driver must be built as built-in and must be probed before
> the IMA subsystem is initialized.
> 
> However, when the TPM device operates over the FF-A protocol using the CRB interface,
> probing fails and returns -EPROBE_DEFER
> if the tpm_crb_ffa device — an FF-A device that provides
> the communication interface to the tpm_crb driver — has not yet been probed.
> 
> This issue occurs because both crb_acpi_driver_init() and
> tpm_crb_ffa_driver_init() are registered with device_initcall.
> As a result, crb_acpi_driver_init() may be invoked before
> tpm_crb_ffa_driver_init(), which is responsible for probing the tpm_crb_ffa device.
> 
> When this happens, IMA fails to detect the TPM device and
> logs the following message:
> 
>   | ima: No TPM chip found, activating TPM-bypass!
> 
> Consequently, it cannot generate the boot_aggregate log with
> the PCR values provided by the TPM.
> 
> To resolve this issue, the tpm_crb_ffa_init() function explicitly attempts to
> probe the tpm_crb_ffa by register tpm_crb_ffa driver so that
> when tpm_crb_ffa device is created before tpm_crb_ffa_init(),
> probe the tpm_crb_ffa device in tpm_crb_ffa_init() to finish probe the
> TPM device completely.
> 
> 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 | 19 ++++++++++++++++---
>  1 file changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c
> index 4ead61f01299..462fcf610020 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,23 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
>   */
>  int tpm_crb_ffa_init(void)
>  {
> +	int ret = 0;
> +
> +	if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
> +		ret = ffa_register(&tpm_crb_ffa_driver);
> +		if (ret) {
> +			tpm_crb_ffa = ERR_PTR(-ENODEV);
> +			return ret;
> +		}
> +	}
> +
>  	if (!tpm_crb_ffa)
> -		return -ENOENT;
> +		ret = -ENOENT;
>  
>  	if (IS_ERR_VALUE(tpm_crb_ffa))
> -		return -ENODEV;
> +		ret = -ENODEV;
>  
> -	return 0;
> +	return ret;
>  }
>  EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
>  
> @@ -369,7 +380,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}
> 

NAK

BR, Jarkko

Re: [PATCH v4 0/2] generate boot_aggregate log in IMA with TPM using CRB over FF-A

[Yeoreum Yun]

Hi Jarkko,

> On Wed, Jun 18, 2025 at 11:23:00AM +0100, Yeoreum Yun wrote:
> > To ensure the TPM device operating over the FF-A protocol with
> > the CRB interface is probed before IMA initialization,
> > the following conditions must be met:
> >
> >    1. The corresponding ffa_device must be registered,
> >       which is done via ffa_init().
> >
> >    2. The tpm_crb_driver must successfully probe this device via
> >       tpm_crb_ffa_init().
> >
> >    3. The tpm_crb driver using CRB over FF-A can then
> >       be probed successfully. (See crb_acpi_add() and
> >       tpm_crb_ffa_init() for reference.)
> >
> > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > all registered with device_initcall, which means crb_acpi_driver_init() may
> > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
>
> I get the ffa_init() part i.e, moving it earlier. However for
> tpm_crb_ffa_init() and crb_acpi_driver_init(), modules.dep
> takes care that they are loaded in order.
> For IMA you will need the driver as built-in but that should
> be handled via kernel config, not via code changes.

In the case of "module" built, it's true.
However what I tell here is when "tpm_crb" and "tpm_crb_ffa" is built
as "built-in" in this case, it couldn't make a "dependency" between
the same initcall level: here is the case of this.

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

in this case, wihtout code change, the crb_acpi_driver_init()
is failed since tpm_crb_ffa_driver_init() is called later.

and this couldn't be solved with kconfig --
ARM_FFA_TRANSPORT=y && CONFIG_TCG_CRB=y && CONFIG_TCG_CRB_FFA=y.

The Patch #2 is to proing the tpm_crb_ffa as part of
crb_acpi_driver_init() when TPM uses method ARM-FFA.

If there's another suggestion, let me know please.

Thanks

--
Sincerely,
Yeoreum Yun

Re: [PATCH v4 2/2] tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in

[Yeoreum Yun]

Hi Jarkkok,

> > --- 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,23 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
> >   */
> >  int tpm_crb_ffa_init(void)
> >  {
> > +	int ret = 0;
> > +
> > +	if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
> > +		ret = ffa_register(&tpm_crb_ffa_driver);
> > +		if (ret) {
> > +			tpm_crb_ffa = ERR_PTR(-ENODEV);
> > +			return ret;
> > +		}
> > +	}
> > +
> >  	if (!tpm_crb_ffa)
> > -		return -ENOENT;
> > +		ret = -ENOENT;
> >
> >  	if (IS_ERR_VALUE(tpm_crb_ffa))
> > -		return -ENODEV;
> > +		ret = -ENODEV;
> >
> > -	return 0;
> > +	return ret;
> >  }
> >  EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
> >
> > @@ -369,7 +380,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}
> >
>
> NAK

If you NACK with your comment on the cover letter,
Would you check the my comments please?

Actually, this wouldn't be fixed with the Kconfig.

Thanks

--
Sincerely,
Yeoreum Yun

Re: [PATCH v4 0/2] generate boot_aggregate log in IMA with TPM using CRB over FF-A

[Jarkko Sakkinen]

On Wed, Jun 25, 2025 at 11:36:19AM +0100, Yeoreum Yun wrote:
> Hi Jarkko,
> 
> > On Wed, Jun 18, 2025 at 11:23:00AM +0100, Yeoreum Yun wrote:
> > > To ensure the TPM device operating over the FF-A protocol with
> > > the CRB interface is probed before IMA initialization,
> > > the following conditions must be met:
> > >
> > >    1. The corresponding ffa_device must be registered,
> > >       which is done via ffa_init().
> > >
> > >    2. The tpm_crb_driver must successfully probe this device via
> > >       tpm_crb_ffa_init().
> > >
> > >    3. The tpm_crb driver using CRB over FF-A can then
> > >       be probed successfully. (See crb_acpi_add() and
> > >       tpm_crb_ffa_init() for reference.)
> > >
> > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> >
> > I get the ffa_init() part i.e, moving it earlier. However for
> > tpm_crb_ffa_init() and crb_acpi_driver_init(), modules.dep
> > takes care that they are loaded in order.
> > For IMA you will need the driver as built-in but that should
> > be handled via kernel config, not via code changes.
> 
> In the case of "module" built, it's true.
> However what I tell here is when "tpm_crb" and "tpm_crb_ffa" is built
> as "built-in" in this case, it couldn't make a "dependency" between
> the same initcall level: here is the case of this.
> 
> 0000000000000888 l       .initcall6.init>-------0000000000000000 crb_acpi_driver_init
> 000000000000088c l       .initcall6.init>-------0000000000000000 tpm_crb_ffa_driver_init
> 
> in this case, wihtout code change, the crb_acpi_driver_init()
> is failed since tpm_crb_ffa_driver_init() is called later.
> 
> and this couldn't be solved with kconfig --
> ARM_FFA_TRANSPORT=y && CONFIG_TCG_CRB=y && CONFIG_TCG_CRB_FFA=y.
> 
> The Patch #2 is to proing the tpm_crb_ffa as part of
> crb_acpi_driver_init() when TPM uses method ARM-FFA.
> 
> If there's another suggestion, let me know please.

Hmm.. I actually got what you mean now. I was looking this from
wrong angle. I think we can pick these patches!

Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

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

BR, Jarkko

Re: [PATCH v4 0/2] generate boot_aggregate log in IMA with TPM using CRB over FF-A

[Jarkko Sakkinen]

On Wed, Jun 25, 2025 at 07:59:53PM +0300, Jarkko Sakkinen wrote:
> On Wed, Jun 25, 2025 at 11:36:19AM +0100, Yeoreum Yun wrote:
> > Hi Jarkko,
> > 
> > > On Wed, Jun 18, 2025 at 11:23:00AM +0100, Yeoreum Yun wrote:
> > > > To ensure the TPM device operating over the FF-A protocol with
> > > > the CRB interface is probed before IMA initialization,
> > > > the following conditions must be met:
> > > >
> > > >    1. The corresponding ffa_device must be registered,
> > > >       which is done via ffa_init().
> > > >
> > > >    2. The tpm_crb_driver must successfully probe this device via
> > > >       tpm_crb_ffa_init().
> > > >
> > > >    3. The tpm_crb driver using CRB over FF-A can then
> > > >       be probed successfully. (See crb_acpi_add() and
> > > >       tpm_crb_ffa_init() for reference.)
> > > >
> > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > >
> > > I get the ffa_init() part i.e, moving it earlier. However for
> > > tpm_crb_ffa_init() and crb_acpi_driver_init(), modules.dep
> > > takes care that they are loaded in order.
> > > For IMA you will need the driver as built-in but that should
> > > be handled via kernel config, not via code changes.
> > 
> > In the case of "module" built, it's true.
> > However what I tell here is when "tpm_crb" and "tpm_crb_ffa" is built
> > as "built-in" in this case, it couldn't make a "dependency" between
> > the same initcall level: here is the case of this.
> > 
> > 0000000000000888 l       .initcall6.init>-------0000000000000000 crb_acpi_driver_init
> > 000000000000088c l       .initcall6.init>-------0000000000000000 tpm_crb_ffa_driver_init
> > 
> > in this case, wihtout code change, the crb_acpi_driver_init()
> > is failed since tpm_crb_ffa_driver_init() is called later.
> > 
> > and this couldn't be solved with kconfig --
> > ARM_FFA_TRANSPORT=y && CONFIG_TCG_CRB=y && CONFIG_TCG_CRB_FFA=y.
> > 
> > The Patch #2 is to proing the tpm_crb_ffa as part of
> > crb_acpi_driver_init() when TPM uses method ARM-FFA.
> > 
> > If there's another suggestion, let me know please.
> 
> Hmm.. I actually got what you mean now. I was looking this from
> wrong angle. I think we can pick these patches!
> 
> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> 
> > 
> > Thanks
> > 
> > --
> > Sincerely,
> > Yeoreum Yun
> 
> BR, Jarkko

Applied.

BR, Jarkko

Re: [PATCH v4 2/2] tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in

[Jarkko Sakkinen]

On Wed, Jun 25, 2025 at 11:37:44AM +0100, Yeoreum Yun wrote:
> Hi Jarkkok,
> 
> > > --- 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,23 @@ static int tpm_crb_ffa_to_linux_errno(int errno)
> > >   */
> > >  int tpm_crb_ffa_init(void)
> > >  {
> > > +	int ret = 0;
> > > +
> > > +	if (!IS_MODULE(CONFIG_TCG_ARM_CRB_FFA)) {
> > > +		ret = ffa_register(&tpm_crb_ffa_driver);
> > > +		if (ret) {
> > > +			tpm_crb_ffa = ERR_PTR(-ENODEV);
> > > +			return ret;
> > > +		}
> > > +	}
> > > +
> > >  	if (!tpm_crb_ffa)
> > > -		return -ENOENT;
> > > +		ret = -ENOENT;
> > >
> > >  	if (IS_ERR_VALUE(tpm_crb_ffa))
> > > -		return -ENODEV;
> > > +		ret = -ENODEV;
> > >
> > > -	return 0;
> > > +	return ret;
> > >  }
> > >  EXPORT_SYMBOL_GPL(tpm_crb_ffa_init);
> > >
> > > @@ -369,7 +380,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}
> > >
> >
> > NAK
> 
> If you NACK with your comment on the cover letter,
> Would you check the my comments please?
> 
> Actually, this wouldn't be fixed with the Kconfig.

I got into the same page (see my response to your response at 0/2) :-)

Thanks for the patience.

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

BR, Jarkko

Re: [PATCH v4 0/2] generate boot_aggregate log in IMA with TPM using CRB over FF-A

[Sudeep Holla]

On Wed, Jun 25, 2025 at 08:01:51PM +0300, Jarkko Sakkinen wrote:
> On Wed, Jun 25, 2025 at 07:59:53PM +0300, Jarkko Sakkinen wrote:
> > On Wed, Jun 25, 2025 at 11:36:19AM +0100, Yeoreum Yun wrote:
> > > Hi Jarkko,
> > > 
> > > > On Wed, Jun 18, 2025 at 11:23:00AM +0100, Yeoreum Yun wrote:
> > > > > To ensure the TPM device operating over the FF-A protocol with
> > > > > the CRB interface is probed before IMA initialization,
> > > > > the following conditions must be met:
> > > > >
> > > > >    1. The corresponding ffa_device must be registered,
> > > > >       which is done via ffa_init().
> > > > >
> > > > >    2. The tpm_crb_driver must successfully probe this device via
> > > > >       tpm_crb_ffa_init().
> > > > >
> > > > >    3. The tpm_crb driver using CRB over FF-A can then
> > > > >       be probed successfully. (See crb_acpi_add() and
> > > > >       tpm_crb_ffa_init() for reference.)
> > > > >
> > > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > >
> > > > I get the ffa_init() part i.e, moving it earlier. However for
> > > > tpm_crb_ffa_init() and crb_acpi_driver_init(), modules.dep
> > > > takes care that they are loaded in order.
> > > > For IMA you will need the driver as built-in but that should
> > > > be handled via kernel config, not via code changes.
> > > 
> > > In the case of "module" built, it's true.
> > > However what I tell here is when "tpm_crb" and "tpm_crb_ffa" is built
> > > as "built-in" in this case, it couldn't make a "dependency" between
> > > the same initcall level: here is the case of this.
> > > 
> > > 0000000000000888 l       .initcall6.init>-------0000000000000000 crb_acpi_driver_init
> > > 000000000000088c l       .initcall6.init>-------0000000000000000 tpm_crb_ffa_driver_init
> > > 
> > > in this case, wihtout code change, the crb_acpi_driver_init()
> > > is failed since tpm_crb_ffa_driver_init() is called later.
> > > 
> > > and this couldn't be solved with kconfig --
> > > ARM_FFA_TRANSPORT=y && CONFIG_TCG_CRB=y && CONFIG_TCG_CRB_FFA=y.
> > > 
> > > The Patch #2 is to proing the tpm_crb_ffa as part of
> > > crb_acpi_driver_init() when TPM uses method ARM-FFA.
> > > 
> > > If there's another suggestion, let me know please.
> > 
> > Hmm.. I actually got what you mean now. I was looking this from
> > wrong angle. I think we can pick these patches!
> > 
> > Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> > 
> > > 
> > > Thanks
> > > 
> > > --
> > > Sincerely,
> > > Yeoreum Yun
> > 
> > BR, Jarkko
> 
> Applied.

If you are applying 1/2 too, feel free to add

Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>

I was initially thinking of taking it separately as there is no strict
build dependency. But I am fine if you can take them together.

-- 
Regards,
Sudeep

Re: [PATCH v4 0/2] generate boot_aggregate log in IMA with TPM using CRB over FF-A

[Jarkko Sakkinen]

On Wed, Jun 25, 2025 at 08:35:33PM +0100, Sudeep Holla wrote:
> On Wed, Jun 25, 2025 at 08:01:51PM +0300, Jarkko Sakkinen wrote:
> > On Wed, Jun 25, 2025 at 07:59:53PM +0300, Jarkko Sakkinen wrote:
> > > On Wed, Jun 25, 2025 at 11:36:19AM +0100, Yeoreum Yun wrote:
> > > > Hi Jarkko,
> > > > 
> > > > > On Wed, Jun 18, 2025 at 11:23:00AM +0100, Yeoreum Yun wrote:
> > > > > > To ensure the TPM device operating over the FF-A protocol with
> > > > > > the CRB interface is probed before IMA initialization,
> > > > > > the following conditions must be met:
> > > > > >
> > > > > >    1. The corresponding ffa_device must be registered,
> > > > > >       which is done via ffa_init().
> > > > > >
> > > > > >    2. The tpm_crb_driver must successfully probe this device via
> > > > > >       tpm_crb_ffa_init().
> > > > > >
> > > > > >    3. The tpm_crb driver using CRB over FF-A can then
> > > > > >       be probed successfully. (See crb_acpi_add() and
> > > > > >       tpm_crb_ffa_init() for reference.)
> > > > > >
> > > > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > > >
> > > > > I get the ffa_init() part i.e, moving it earlier. However for
> > > > > tpm_crb_ffa_init() and crb_acpi_driver_init(), modules.dep
> > > > > takes care that they are loaded in order.
> > > > > For IMA you will need the driver as built-in but that should
> > > > > be handled via kernel config, not via code changes.
> > > > 
> > > > In the case of "module" built, it's true.
> > > > However what I tell here is when "tpm_crb" and "tpm_crb_ffa" is built
> > > > as "built-in" in this case, it couldn't make a "dependency" between
> > > > the same initcall level: here is the case of this.
> > > > 
> > > > 0000000000000888 l       .initcall6.init>-------0000000000000000 crb_acpi_driver_init
> > > > 000000000000088c l       .initcall6.init>-------0000000000000000 tpm_crb_ffa_driver_init
> > > > 
> > > > in this case, wihtout code change, the crb_acpi_driver_init()
> > > > is failed since tpm_crb_ffa_driver_init() is called later.
> > > > 
> > > > and this couldn't be solved with kconfig --
> > > > ARM_FFA_TRANSPORT=y && CONFIG_TCG_CRB=y && CONFIG_TCG_CRB_FFA=y.
> > > > 
> > > > The Patch #2 is to proing the tpm_crb_ffa as part of
> > > > crb_acpi_driver_init() when TPM uses method ARM-FFA.
> > > > 
> > > > If there's another suggestion, let me know please.
> > > 
> > > Hmm.. I actually got what you mean now. I was looking this from
> > > wrong angle. I think we can pick these patches!
> > > 
> > > Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> > > 
> > > > 
> > > > Thanks
> > > > 
> > > > --
> > > > Sincerely,
> > > > Yeoreum Yun
> > > 
> > > BR, Jarkko
> > 
> > Applied.
> 
> If you are applying 1/2 too, feel free to add
> 
> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> 
> I was initially thinking of taking it separately as there is no strict
> build dependency. But I am fine if you can take them together.

Hmm.. Yeah, if you insist to take them, that's fine for me too.

That said, I'm also happy to take care of them :-)

I'll append your review.

> 
> -- 
> Regards,
> Sudeep

BR, Jarkko

Re: [PATCH v4 0/2] generate boot_aggregate log in IMA with TPM using CRB over FF-A

[Sudeep Holla]

On Thu, Jun 26, 2025 at 12:47:17AM +0300, Jarkko Sakkinen wrote:
> On Wed, Jun 25, 2025 at 08:35:33PM +0100, Sudeep Holla wrote:
> > 
> > If you are applying 1/2 too, feel free to add
> > 
> > Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> > 
> > I was initially thinking of taking it separately as there is no strict
> > build dependency. But I am fine if you can take them together.
> 
> Hmm.. Yeah, if you insist to take them, that's fine for me too.
> 

Ignore me 😄

> That said, I'm also happy to take care of them :-)
> 

Yes, please take them via your tree.

> I'll append your review.

Thanks!

-- 
Regards,
Sudeep

Re: [PATCH v4 0/2] generate boot_aggregate log in IMA with TPM using CRB over FF-A

[Jarkko Sakkinen]

On Thu, Jun 26, 2025 at 08:53:39PM +0100, Sudeep Holla wrote:
> On Thu, Jun 26, 2025 at 12:47:17AM +0300, Jarkko Sakkinen wrote:
> > On Wed, Jun 25, 2025 at 08:35:33PM +0100, Sudeep Holla wrote:
> > > 
> > > If you are applying 1/2 too, feel free to add
> > > 
> > > Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> > > 
> > > I was initially thinking of taking it separately as there is no strict
> > > build dependency. But I am fine if you can take them together.
> > 
> > Hmm.. Yeah, if you insist to take them, that's fine for me too.
> > 
> 
> Ignore me 😄
> 
> > That said, I'm also happy to take care of them :-)
> > 
> 
> Yes, please take them via your tree.
> 
> > I'll append your review.
> 
> Thanks!

OK cool, cool just syncing up :-)

> 
> -- 
> Regards,
> Sudeep