Message-ID: <aEhDY4VlkIPYAjPE@e129823.arm.com>
Date: Tue, 10 Jun 2025 15:38:27 +0100
From: Yeoreum Yun <yeoreum.yun@....com>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: sudeep.holla@....com, peterhuewe@....de, jgg@...pe.ca,
	stuart.yoder@....com, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-integrity@...r.kernel.org
Subject: Re: [PATCH v2 0/2] fix failure of integration IMA with tpm_crb_ffa

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

Powered by blists - more mailing lists