Re: TPM selftest failure in 4.15

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2018-02-09 at 07:26 -0500, Mimi Zohar wrote:
> On Fri, 2018-02-09 at 12:02 +0200, Jarkko Sakkinen wrote:
> > 
> > On Thu, Feb 08, 2018 at 09:02:00AM -0800, James Bottomley wrote:
> > > 
> > > There is an identified regression: the TPM driver will now
> > > periodically
> > > fail to attach.  However, there's no point reviewing until we
> > > agree
> > > what the fix is.  I was just waiting to verify this fixed my
> > > problem
> > > (which means seeing the messages it spits out proving the TPM has
> > > remained in self test).  I have now seen this and the driver
> > > still
> > > works, so I can submit a formal patch.
> > 
> > For the self-test the duration falls down to 2 seconds as the specs
> > do
> > not contain any well-defined duration for it, or at least I haven't
> > found it.
> > 
> > I see three alternative ways the fix the self-test:
> > 
> > 1. Execute self-test with fullTest = YES.
> > 2. Have a flag TPM_CHIP_TESTING that is set when the self-test is
> >    started. Issue a warning on time-out. Check for this flag in
> >    tpm_transmit_cmd() and tpm_write() and resend self-test command
> >    if the flag is stil test before the actual command. Return
> > -EBUSY
> >    and print a warning if self-test is still active.
> > 3. Increase the duration to the "correct" value if we have one.
> 
> Please take into account that the TPM must complete initialization
> BEFORE IMA looks for the TPM, otherwise IMA goes into TPM-bypass
> mode.  This consistently happens with a full self-test (option 1).
> Increasing the wait duration will most likely cause this to happen as
> well (option 2).
> 
> Based on James' patch description, which says "There are various
> theories that resending the self-test command actually causes the
> tests to restart and thus triggers more TPM_RC_TESTING returns until
> the timeout is exceeded", I think IMA's detecting the TPM, by doing a
> PCR read, will cause the self-test to restart (option 2).

Actually, no, only doing another selftest seems to restart.  Any other
command will either get a normal return (if the TPM has already tested
the subsystem) or an RC_TESTING return indicate it's still being
tested.  It seems that the PCRs are one of the earliest things to come
on-line, so IMA always works.  This is on my current laptop where I'm
running this patch with IMA: I no longer see the IMA bypass message and
IMA comes up normally.

The delay loop in transmit is instrumented, so I never see the TPM
return RC_TESTING to a PCR read even if it comes out of selftest as
RC_TESTING (I'll keep looking, though, it's only been a few days).

> Reverting the patch that enabled the TPM full self-test, or
> commenting out self-test completely, allows IMA to properly find the
> TPM.
> 
> Side note, if the kernel emits TPM initialization warnings, there
> should be a successfully completed message as well.

It would actually be really nice if we printed TPM identification
information as well (having just had to go over a load of systems and
answer the question what TPM do they have ...)

James




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux