Message-ID: <b75fd04643daf5aab5a1fc115e8fbfca9a381f8d.camel@mniewoehner.de>
Date:   Tue, 25 Dec 2018 14:55:49 +0100
From:   Michael Niewöhner <linux@...ewoehner.de>
To:     Mimi Zohar <zohar@...ux.ibm.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        James Bottomley <James.Bottomley@...senPartnership.com>,
        peterhuewe@....de, jgg@...pe.ca, arnd@...db.de,
        linux-integrity@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Nayna Jain <nayna@...ux.ibm.com>,
        Ken Goldman <kgold@...ux.ibm.com>
Subject: Re: tpm_tis TPM2.0 not detected on cold boot

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.
> 
> 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.
> 
> 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...
> 
> > 
> > > 
> > > 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

> 
> > Mimi
> > 
> 
> There is another issue but I don't know if both are related. Maybe that's just
> a
> timing issue...
> 
> root@...ian:~# dd if=/dev/hwrng bs=1 count=1
> dd: error reading '/dev/hwrng': Operation not permitted
> 0+0 records in
> 0+0 records out
> 0 bytes copied, 0.755958 s, 0.0 kB/s
> root@...ian:~# dd if=/dev/hwrng bs=1 count=1 | xxd; dd if=/dev/hwrng bs=1
> count=1 | xxd
> dd: error reading '/dev/hwrng': Operation not permitted
> 0+0 records in
> 0+0 records out
> 0 bytes copied, 0.755697 s, 0.0 kB/s
> 1+0 records in
> 1+0 records out
> 00000000: 52                                       R
> 1 byte copied, 0.0106268 s, 0.1 kB/s
> 
> 
> Michael

Powered by blists - more mailing lists