Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   "Jorge Ramirez-Ortiz, Foundries" <jorge@foundries.io>
Date:   Thu, 10 Jun 2021 17:18:01 +0200
To:     Mimi Zohar <zohar@linux.ibm.com>
Cc:     "Jorge Ramirez-Ortiz, Foundries" <jorge@foundries.io>,
        dmitry.kasatkin@gmail.com, jmorris@namei.org, serge@hallyn.com,
        linux-integrity@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        linux-kernel@vger.kernel.org, Jarkko Sakkinen <jarkko@kernel.org>
Subject: Re: ima - wait for tpm load
Message-ID: <20210610151801.GA19687@trex>
References: <20210610071633.GA30216@trex>
 <b3c1f5a0a37419fac51d570cd1c8e521f59cee14.camel@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b3c1f5a0a37419fac51d570cd1c8e521f59cee14.camel@linux.ibm.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

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
>