Bugzilla – Bug 1222098
tpm resource manager - tpm2_save-context failed with error 0x0901
Last modified: 2024-04-04 05:48:46 UTC
dmesg shows: // [ 200.968893] tpm tpm0: tpm2_save_context: failed with a TPM error 0x0901 // [ 200.972263] tpm tpm0: A TPM error (459) occurred flushing context // [ 200.974210] tpm tpm0: tpm2_commit_space: error -14 This is discussed in the tpm2 tools project here: https://github.com/tpm2-software/tpm2-tools/issues/2279 The summary is that the in kernel resource managers context gap max is too low. This should be increased to prevent resource exhaustion. It is actually possible to trigger this even if you are correctly flushing session contexts after use.
(In reply to William Brown from comment #0) > dmesg shows: > > // [ 200.968893] tpm tpm0: tpm2_save_context: failed with a TPM error 0x0901 > // [ 200.972263] tpm tpm0: A TPM error (459) occurred flushing context > // [ 200.974210] tpm tpm0: tpm2_commit_space: error -14 > > This is discussed in the tpm2 tools project here: > > https://github.com/tpm2-software/tpm2-tools/issues/2279 > > The summary is that the in kernel resource managers context gap max is too > low. > > This should be increased to prevent resource exhaustion. It is actually > possible to trigger this even if you are correctly flushing session contexts > after use. The above looks like a pretty old issue (around 2020). That said, no changes done in kernel side? Or do you suggest something we need to change in config or such?
> > The above looks like a pretty old issue (around 2020). That said, no > changes done in kernel side? Or do you suggest something we need to change > in config or such? As in, the issue from 2020 that was reported above nominates that it is the linux kernel tpm resource manager at fault, and that changes to the kernel resource manager are required to prevent the issue. It's quite trivial to reproduce - even just working with the examples in https://github.com/parallaxsecond/rust-tss-esapi/ after a few executions the tpmrm will stop responding with this error.
Then the best would be to report to the kernel upstream devs. Care to do that?
(In reply to Takashi Iwai from comment #3) > Then the best would be to report to the kernel upstream devs. > Care to do that? I don't feel comfortable reporting an issue to upstream kernel directly. That's why I'm reporting it here.
It's an upstream issue as you're reporting for Tumbleweed, so the best place to address is there :)
Well this issue affects tumbleweed, and may block kanidms unix client working properly as well as himmelblau, both of which use the tpm via tpmrm0. So it seems like an issue that affects tumbleweed to me. (Kanidm is being used as an IDM within opensuse infrastructure now). I'm also not a kernel developer. The kernel community has a community of toxicity and hostility. And I've been on the receiving end of that in the past. I'm not signed up to the bug trackers. I'm not on the mailing lists. I have no idea where I would even start to report a bug, and given past experience I'm sure if I don't report it in precisely the correct way then I'll surely be sent a list of derogatory comments. This is why I'm asking you *here* to report it and manage the bug on my behalf. I don't know the process. I'm not reporting it upstream. Put another way. If you reported a bug to me about LDAP or IDM I would not ask you to report it upstream. I would report it upstream on your behalf because I know the in's an outs of the process, and I would take it from there. I hope you will do the same for me now.
It's no longer a wild west as in 20 years ago, and there is no much reason to hesitate. It's really better you reporting it since you have the specific system and program to test with, and have better understanding around the TPM handling from user-space side. (Though, in the end it might be unchanged, as the issue could be a firmware issue; I thought the value TPM2_PT_CONTEXT_GAP_MAX is read from the system, not what the kernel defines?) When you reporting, feel free to put me (tiwai@suse.de) to Cc in case you need assistance from the distro kernel side.
FWIW, get_maintainers gives: Peter Huewe <peterhuewe@gmx.de> (maintainer:TPM DEVICE DRIVER) Jarkko Sakkinen <jarkko@kernel.org> (maintainer:TPM DEVICE DRIVER) Jason Gunthorpe <jgg@ziepe.ca> (reviewer:TPM DEVICE DRIVER) linux-integrity@vger.kernel.org (open list:TPM DEVICE DRIVER) linux-kernel@vger.kernel.org (open list)
I'm not really thrilled to do this but I have sent the email. Lets pray it goes okay.
Great, thanks! Your post appeared at https://lore.kernel.org/all/424B3F10-D91C-4F47-B33C-BB66FE4DB91A@suse.de/ Let's track there.