On Sat, 2018-12-29 at 22:33 -0500, Mimi Zohar wrote: > 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 Exactly, soft reboot / warm boot works. What I don't understand is WHY it works. If it was a hardware problem I would expect it not to work after it previously failed after a cold boot but that is not the case. The warm reboot / kexec does reinitialize anything. That means maybe it would be sufficient to reinitialize that - whatever it is - to get the TPM working instead of needing a full warm reboot. > difference is that on a cold boot, the TPM takes longer to initialize. Well, as I said. Waiting for 10, 20 or even 60 seconds in the boot manager does not solve the problem. So the problem is NOT that the TPM takes longer to initialize. Even adding a delay of 20 seconds before TPM init does not solve that while that should be more than enough time. > > > > 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 >
