On Tue, 2020-04-21 at 23:25 +0300, Jarkko Sakkinen wrote: > On Tue, Apr 21, 2020 at 10:36:04AM -0400, Mimi Zohar wrote: > > On Mon, 2020-04-20 at 15:28 -0700, James Bottomley wrote: > > > On Mon, 2020-04-20 at 23:46 +0300, Jarkko Sakkinen wrote: > > > > <snip> > > > > > 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@xxxxxxxxxxxxxxxxxx/ > > > > The original reason for us needing to improve the TPM performance was > > due to the kernel scheduler change. Refer to commit a233a0289cf9 > > ("tpm: msleep() delays - replace with usleep_range() in i2c nuvoton > > driver"). That scheduler change prevented systems from booting. > > Bisecting the kernel to figure out the problem wasn't very > > productive. > > > > At least any TPM changes that affect the TPM performance really need > > to take into account IMA requirements. > > Thanks Mimi. > > With my dynamic proposal it would work as it works now for system > where it worked anyway, and would fix the systems where timeouts > were too short. Sure, but please remember this thread started out addressing an STM TPM bug, not James' timeouts. This part of the thread should be re- named. Mimi
