ima - wait for tpm load

I am enabling IMA on a ZynqMP based platform using an SPI based TPM
from Infineon.

The SPI TPM driver is built-in but since the IMA is initalized from a
late_initcall, IMA never finds the TPM.

Is there a recomended way to work around this issue?

fio@uz3cg-dwg:~$ dmesg | grep tpm
[    3.381181] tpm_tis_spi spi1.1: 2.0 TPM (device-id 0x1B, rev-id 22)
[    3.423608] tpm tpm0: A TPM error (256) occurred attempting the self test
[    3.430406] tpm tpm0: starting up the TPM manually

fio@uz3cg-dwg:~$ dmesg | grep ima
[    3.525741] ima: No TPM chip found, activating TPM-bypass!
[    3.531233] ima: Allocated hash algorithm: sha1

TIA

jorge

[Cc'ing Jarkko]

On Thu, 2021-06-10 at 09:16 +0200, Jorge Ramirez-Ortiz, Foundries
wrote:

I am enabling IMA on a ZynqMP based platform using an SPI based TPM
from Infineon.

The SPI TPM driver is built-in but since the IMA is initalized from a
late_initcall, IMA never finds the TPM.

Is there a recomended way to work around this issue?

fio@uz3cg-dwg:~$ dmesg | grep tpm
[    3.381181] tpm_tis_spi spi1.1: 2.0 TPM (device-id 0x1B, rev-id 22)
[    3.423608] tpm tpm0: A TPM error (256) occurred attempting the self test
[    3.430406] tpm tpm0: starting up the TPM manually

fio@uz3cg-dwg:~$ dmesg | grep ima
[    3.525741] ima: No TPM chip found, activating TPM-bypass!
[    3.531233] ima: Allocated hash algorithm: sha1

Lengthening the TPM timeout, executing the TPM self test have been past
reasons for the TPM not to initialize prior to IMA.

(Missing from this bug report is the kernel version.)

thanks,

Mimi

On 10/06/21, Mimi Zohar wrote:

[Cc'ing Jarkko]

On Thu, 2021-06-10 at 09:16 +0200, Jorge Ramirez-Ortiz, Foundries
wrote:

quoted

I am enabling IMA on a ZynqMP based platform using an SPI based TPM
from Infineon.

The SPI TPM driver is built-in but since the IMA is initalized from a
late_initcall, IMA never finds the TPM.

Is there a recomended way to work around this issue?

fio@uz3cg-dwg:~$ dmesg | grep tpm
[    3.381181] tpm_tis_spi spi1.1: 2.0 TPM (device-id 0x1B, rev-id 22)
[    3.423608] tpm tpm0: A TPM error (256) occurred attempting the self test
[    3.430406] tpm tpm0: starting up the TPM manually

fio@uz3cg-dwg:~$ dmesg | grep ima
[    3.525741] ima: No TPM chip found, activating TPM-bypass!
[    3.531233] ima: Allocated hash algorithm: sha1

Lengthening the TPM timeout, executing the TPM self test have been past
reasons for the TPM not to initialize prior to IMA.

right, I can understand this.

The problem in this case is that tpm_chip_register() is taking too
long so by the time it executes tpm_add_char_device(chip) is called,
ima has already given up.

The way I am working around this is just by adding a new flag and
providing the chip in idr_alloc (so ima can find it).

Then add an 'enable' flag to the chip structure that ima can use to
wait on.

@@ -333,8 +345,13 @@ struct tpm_chip *tpm_chip_alloc(struct device *pdev,

        chip->ops = ops;

+ if (ops->flags & TPM_OPS_SLOW_STARTUP)
+         chip->flags |= TPM_CHIP_FLAG_SLOW_STARTUP;
+
        mutex_lock(&idr_lock);
-   rc = idr_alloc(&dev_nums_idr, NULL, 0, TPM_NUM_DEVICES, GFP_KERNEL);
+ rc = idr_alloc(&dev_nums_idr,
+                chip->flags & TPM_CHIP_FLAG_SLOW_STARTUP ? chip : NULL,
+                0, TPM_NUM_DEVICES, GFP_KERNEL);
        mutex_unlock(&idr_lock);
        if (rc < 0) {
                dev_err(pdev, "No available tpm device numbers\n");

(Missing from this bug report is the kernel version.)

um, didnt think of it as a bug report - the feature is clearly not
synchronized so there can be no guarantees about available TPMs being
used. 

but yes, this is happening on 5.10.42 using tpm_tis_spi to connect to
infineon SLM9670

thanks,

Mimi

On Thu, 2021-06-10 at 17:18 +0200, Jorge Ramirez-Ortiz, Foundries
wrote:

As I recall "extend" works pretty much from the beginning.  There's no
need to wait for the self test to complete.   Registering the TPM early
might be enough without having to wait.  Or maybe check the selftest
result.

Thank you for looking into resolving this problem!

Mimi

quoted

(Missing from this bug report is the kernel version.)

um, didnt think of it as a bug report - the feature is clearly not
synchronized so there can be no guarantees about available TPMs being
used. 

but yes, this is happening on 5.10.42 using tpm_tis_spi to connect to
infineon SLM9670

On 6/10/2021 4:31 PM, Mimi Zohar wrote:

As I recall "extend" works pretty much from the beginning.  There's no
need to wait for the self test to complete.   Registering the TPM early
might be enough without having to wait.  Or maybe check the selftest
result.

TPM 2.0 depends somewhat on the type of self test - there are several
options.  They will in some sense block other commands that use
the angorithm.

The TPM is permitted to do an extend before the hash algorithm is
tested (just not return a result) but I don't think it's required.

So:

- self test
- extend

may permit the extend to proceed while the self test is
happening, but it may not.