From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>,
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>,
Paul Menzel <pmenzel@molgen.mpg.de>,
linux-integrity <linux-integrity@vger.kernel.org>
Subject: Re: TPM selftest failure in 4.15
Date: Fri, 09 Feb 2018 08:23:36 -0800 [thread overview]
Message-ID: <1518193416.3930.10.camel@HansenPartnership.com> (raw)
In-Reply-To: <1518179200.3445.31.camel@linux.vnet.ibm.com>
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
next prev parent reply other threads:[~2018-02-09 16:23 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-01 12:16 TPM selftest failure in 4.15 James Bottomley
2018-02-01 12:21 ` Paul Menzel
2018-02-01 12:42 ` James Bottomley
2018-02-01 15:24 ` James Bottomley
2018-02-01 17:40 ` Jason Gunthorpe
2018-02-01 18:46 ` James Bottomley
2018-02-01 18:59 ` Jason Gunthorpe
2018-02-01 20:00 ` James Bottomley
2018-02-01 20:35 ` Jason Gunthorpe
2018-02-01 21:06 ` James Bottomley
2018-02-08 13:10 ` Jarkko Sakkinen
2018-02-08 17:02 ` James Bottomley
2018-02-09 10:02 ` Jarkko Sakkinen
2018-02-09 10:30 ` Nayna Jain
2018-02-15 12:00 ` Jarkko Sakkinen
2018-02-09 11:47 ` Alexander Steffen
2018-02-15 12:12 ` Jarkko Sakkinen
2018-02-15 15:13 ` Mimi Zohar
2018-02-16 18:30 ` Alexander Steffen
2018-02-19 9:15 ` Nayna Jain
2018-02-19 22:26 ` Jason Gunthorpe
2018-02-16 18:27 ` Alexander Steffen
2018-02-20 13:05 ` Jarkko Sakkinen
2018-02-09 12:26 ` Mimi Zohar
2018-02-09 16:23 ` James Bottomley [this message]
2018-02-09 21:23 ` Mimi Zohar
2018-04-08 18:27 ` Ken Goldman
2018-02-09 16:18 ` James Bottomley
2018-02-08 17:27 ` Ken Goldman
2018-02-01 19:16 ` TPM selftest failure in 4.15 (Dell XPS 13, Nuvoton 6xx) Paul Menzel
2018-02-01 19:17 ` Paul Menzel
2018-02-01 20:12 ` Mario.Limonciello
2018-02-01 21:06 ` Mario.Limonciello
2018-02-01 22:22 ` Jason Gunthorpe
2018-02-02 5:46 ` James Bottomley
2018-02-02 5:46 ` James Bottomley
2018-02-08 16:53 ` Ken Goldman
2018-02-08 13:18 ` Jarkko Sakkinen
2018-02-08 13:05 ` TPM selftest failure in 4.15 Jarkko Sakkinen
2018-02-08 13:03 ` Jarkko Sakkinen
2018-02-08 12:49 ` Jarkko Sakkinen
2018-02-08 18:45 ` Ken Goldman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1518193416.3930.10.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jgg@ziepe.ca \
--cc=linux-integrity@vger.kernel.org \
--cc=pmenzel@molgen.mpg.de \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.