From: Mimi Zohar <zohar@linux.ibm.com>
To: "Michael Niewöhner" <linux@mniewoehner.de>,
"Jarkko Sakkinen" <jarkko.sakkinen@linux.intel.com>,
"James Bottomley" <James.Bottomley@HansenPartnership.com>,
peterhuewe@gmx.de, jgg@ziepe.ca, arnd@arndb.de,
linux-integrity@vger.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>,
"Nayna Jain" <nayna@linux.ibm.com>,
"Ken Goldman" <kgold@linux.ibm.com>
Subject: Re: tpm_tis TPM2.0 not detected on cold boot
Date: Sat, 29 Dec 2018 22:33:57 -0500 [thread overview]
Message-ID: <1546140837.4069.81.camel@linux.ibm.com> (raw)
In-Reply-To: <b75fd04643daf5aab5a1fc115e8fbfca9a381f8d.camel@mniewoehner.de>
On Tue, 2018-12-25 at 14:55 +0100, Michael Niewöhner wrote:
> On Sun, 2018-12-23 at 12:55 +0100, Michael Niewöhner wrote:
> > Hi Mimi,
> >
> > On Sat, 2018-12-22 at 17:53 -0500, Mimi Zohar wrote:
> > > On Sat, 2018-12-22 at 14:47 +0100, Michael Niewöhner wrote:
> > >
> > > > When I remove the timeout and boot directly to the linux kernel, I get
> > > > that
> > > > "2314 TPM-self test error" since it has not finished, yet. The TPM is
> > > > detected
> > > > by IMA and works fine then.
> > > >
> > > > Some more tests showed that any delay before booting the kernel causes the
> > > > TPM
> > > > to not get detected. I tested, 10, 15, 20, 30, 60... seconds. Only in some
> > > > very
> > > > rare cases the TPM got detected.
> > > >
> > > > I wanted to know if the TPM is in an well initialized state at the time of
> > > > that
> > > > error. Since I was not able to get some test/debug kernel patches working
> > > > I
> > > > decided to try kexec. It turned out that the TPM is indeed correctly
> > > > working
> > > > and
> > > > will be detected just fine by linux after kexec!
> > >
> > > No surprise here. kexec would be the equivalent of a soft reboot.
> >
> > Well, I am not that deep in kexec internals but isn't a soft reboot much more
> > than a kexec? I thought kexec would "just" load the new kernel to memory and
> > executes it while a soft reboot goes at least through some UEFI
> > initialization.
> > For example, my pwm fans - in fact the EC - get resetted on a soft reboot,
> > while
> > a kexec does not touch them.
> >
Similarly, the PCRs are not reset on kexec.
> > That is why I wanted to test if there is a different behaviour on kexec
> > compared
> > to a "real" soft reboot. If there was such difference I would have assumed a
> > UEFI bug that does not initialize the TPM correctly.
> > Kexec AFAIK does not invoke any UEFI initialization, so the TPM should be in
> > the
> > same state as before kexec and since there is no difference between sr and
> > kexec
> > I have the feeling there is something wrong in the kernel.
> >
> > Correct me if I am wrong here, please.
But the problem you've described is on a cold boot, not a soft reboot.
Both the soft reboot and kexec are working properly. It seems the
difference is that on a cold boot, the TPM takes longer to initialize.
> > My current workaround is to do a machine_emergency_reboot() when TPM isn't
> > detected correctly. That is a pretty hard workaround but it seems to work for
> > now...
This is a again soft reboot.
>
> > >
> > > >
> > > > Is there anyone having an idea what could be wrong here? I am willing to
> > > > debug
> > > > this but I have really no idea where to start :-(
> > >
> > > A while ago, I was "playing" with a pi. Commenting out
> > > tpm2_do_selftest() seemed to resolve a similar problem, but that was
> > > before James' patches. I don't know if that would make a difference
> > > now.
> >
> > Hm, I will try that..
> >
>
> Unfortunately this did not change anything
Not much I can do now. After vacation, I'll set up the pi to see if
it is working properly with a recent kernel.
Mimi
next prev parent reply other threads:[~2018-12-30 3:34 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-16 13:32 tpm_tis TPM2.0 not detected on cold boot Michael Niewöhner
2018-12-22 13:47 ` Michael Niewöhner
2018-12-22 22:53 ` Mimi Zohar
2018-12-23 11:55 ` Michael Niewöhner
2018-12-25 13:55 ` Michael Niewöhner
2018-12-30 3:33 ` Mimi Zohar [this message]
2018-12-30 13:22 ` Michael Niewöhner
2018-12-31 18:10 ` Ken Goldman
2018-12-31 21:17 ` Mimi Zohar
2019-01-01 16:15 ` Michael Niewöhner
2019-01-01 16:38 ` Mimi Zohar
2019-01-01 16:47 ` Michael Niewöhner
2018-12-31 17:56 ` Ken Goldman
2019-01-03 13:27 ` Jarkko Sakkinen
2019-01-03 13:38 ` Michael Niewöhner
2019-01-03 15:04 ` Jarkko Sakkinen
2019-01-03 15:47 ` Michael Niewöhner
2019-01-04 11:58 ` Michael Niewöhner
2019-01-04 15:28 ` Michael Niewöhner
2019-01-04 18:26 ` Michael Niewöhner
2019-01-10 17:28 ` Jarkko Sakkinen
2019-01-10 18:03 ` Michael Niewöhner
2019-01-10 17:19 ` Jarkko Sakkinen
2019-01-10 18:00 ` Michael Niewöhner
2019-01-03 13:41 ` Jarkko Sakkinen
2019-01-03 13:55 ` Michael Niewöhner
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=1546140837.4069.81.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=arnd@arndb.de \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jgg@ziepe.ca \
--cc=kgold@linux.ibm.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@mniewoehner.de \
--cc=nayna@linux.ibm.com \
--cc=peterhuewe@gmx.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).