On Tue, 2020-04-21 at 23:23 +0300, Jarkko Sakkinen wrote: > On Mon, Apr 20, 2020 at 03:28:06PM -0700, James Bottomley wrote: > > On Mon, 2020-04-20 at 23:46 +0300, Jarkko Sakkinen wrote: [...] > > > Does it matter? > > > > Not if you're the one telling Mimi ... and I'm at least 1 mile from > > the blast radius. > > > > But more seriously: Nayna Jain did a series of patches improving > > the time it takes to poll the TPM for operations precisely because > > the TPM PCR extend was going so slowly: > > > > https://lore.kernel.org/linux-integrity/20180516055125.5685-1-nayna > > @linux.vnet.ibm.com/ > > > > I also reported the issue shortly after that patch was integrated, > > but everyone seemed to think it was just a problem with my TPM chip > > (it's an early Nuvoton field upgraded to 2.0): > > > > https://lore.kernel.org/linux-integrity/1531328689.3260.8.camel@Han > > senPartnership.com/ > > What if we make it dynamic? I.e. if the init code gets -ETIME, then > increase the timeouts? The problem is detecting that you need the updated timeouts. My tpm doesn't fail in init. In fact it manages quite a healthy amount of key operations before going offline. I'm a heavy TPM key user: I use RSA keys for two VPNs, all my ssh keys and so on I got tired of the time RSA takes, so my gpg keys are elliptic curve, but they're the only ones. By the time my TPM fails, I've usually at least booted my desktop, which means several tens of RSA operations have already happened in the TPM. James
