Re: ima - wait for tpm load

["Jorge Ramirez-Ortiz, Foundries" <jorge@foundries.io>]

On 10/06/21, Mimi Zohar wrote:
> [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.

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
>