On Wed, 2024-11-13 at 07:47 -0800, James Bottomley wrote: > On Wed, 2024-11-13 at 15:44 +0100, Christoph Anton Mitterer wrote: > > Hey. > > > > Forwarding myself from: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087331 > > > > Since 6.11.7 (might have also happened with .6, which I've skipped, > > but wasn't the case at least in 6.11.5). > > > > I get: > > Nov 11 17:50:20 heisenberg kernel: tpm tpm0: A TPM error (2306) > > occurred attempting to create NULL primary > > Nov 11 17:50:30 heisenberg kernel: tpm tpm0: A TPM error (2306) > > occurred attempting to create NULL primary > > Nov 11 17:50:41 heisenberg kernel: tpm tpm0: A TPM error (2306) > > occurred attempting to create NULL primary > > Nov 11 17:50:51 heisenberg kernel: tpm tpm0: A TPM error (2306) > > occurred attempting to create NULL primary > > Nov 11 17:51:01 heisenberg kernel: tpm tpm0: A TPM error (2306) > > occurred attempting to create NULL primary > > Nov 11 17:51:11 heisenberg kernel: tpm tpm0: A TPM error (2306) > > occurred attempting to create NULL primary > > 2306 is TPM_RC_OBJECT_MEMORY - out of memory for object contexts. > What it's saying is that somewhere we're missing a context flush. > I'll take a look. Does this happen with the current upstream > kernel? It couldbe a flush got lost as a result of a bad stable > backport. OK, I found it; there's a bug in the handling of create primary on a validation rather than a TPM error (it doesn't flush the handle). However, even when I fix that you're apparently going to get the below message every 10s or so as the TPM tries to init > > > It seems that this doesn't occur on a fresh boot, but only when I > > resume from hibernation: > > That could be more significant, especially with this in the log: > > > Nov 13 12:33:06 heisenberg kernel: tpm tpm0: NULL Seed name > > comparison failed > > Nov 13 12:33:16 heisenberg kernel: tpm tpm0: NULL Seed name > > comparison failed > > Nov 13 12:33:26 heisenberg kernel: tpm tpm0: NULL Seed name > > comparison failed > > I think we might have to expect the NULL name to change on actual > hibernation because unlike suspend to ram it does power off the TPM. I checked the code: we're coming in on the correct path to renew the null seed after hibernation, so it should all work. The problem seems to be that your TPM itself is doing something invalid because the name we calculate for the primary key doesn't match what your TPM says it should be. Absent some form of attack or bus integrity problem, that shouldn't ever happen, so I'm even more curious to know why it worked in 6.11.5 and before and whether current upstream works. I haven't found it yet, but I think the every 10s signature is because the hibernation path is trying to restart the TPM device and won't take no for an answer.
