linux-kernel - Re: ima - wait for tpm load

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 10 Jun 2021 17:18:01 +0200
From:   "Jorge Ramirez-Ortiz, Foundries" <jorge@...ndries.io>
To:     Mimi Zohar <zohar@...ux.ibm.com>
Cc:     "Jorge Ramirez-Ortiz, Foundries" <jorge@...ndries.io>,
        dmitry.kasatkin@...il.com, jmorris@...ei.org, serge@...lyn.com,
        linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-kernel@...r.kernel.org, Jarkko Sakkinen <jarkko@...nel.org>
Subject: Re: ima - wait for tpm load

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@...cg-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@...cg-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
>