lkml.org 
[lkml]   [2018]   [Dec]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: tpm_tis TPM2.0 not detected on cold boot
From
Date
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@debian:~# 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@debian:~# 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


\
 
 \ /
  Last update: 2018-12-25 14:57    [W:0.098 / U:9.408 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site