From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > On Thu, 2023-10-19 at 16:16 +0000, Andreas.Fuchs@xxxxxxxxxxxx wrote: > > > From: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> > > > On Thu, 2023-10-19 at 16:05 +0200, Juergen Repp wrote: > > > > There is an issue related to this problem on github for tpm2-tss: > > > > https://github.com/tpm2-software/tpm2-tss/issues/2691 (/dev/tpmrm > > > > 0 was > > > > used) The error did occur after abbout 200 signing operations when > > > > a second session was opened by a second process at the same time. > > > > Kernel log: > > > > [ 401.923826] tpm tpm0: tpm2_save_context: failed with a TPM error > > > > 0x0901 [ 401.925049] tpm tpm0: A TPM error (459) occurred > > > > flushing context > > > > > > I'm afraid that's a known problem with the Intel TSS: it saves the > > > context, which will cause a gapping error if you keep it saved while > > > doing other context requiring operations. The solutions are either > > > to implement degapping in the kernel or persuade the Intel TSS not > > > to save contexts unnecessarily. > > > > This is independent of the TSS used. > > When you have one long lasting session being used seldomly (i.e. in > > Application A) and another session or multiple sessions being used > > frequently (i.e. in Application B), then you will hit this problem at > > some point. > > As such ANY resource manager (in kernel or outside) needs to implement > > session ungaping, otherwise it will fail such scenarios. > > That's true, but in real life the use of sessions tends to be short lived and not context saved (usually short enough that this doesn't even cause a context save inside the kernel rm). You can see this in the TPM code in gnupg, or any of the engines/providers. That's not to say we shouldn't do degapping but, because most common uses in the field don't need it, there's been little pressure on anyone to actually write the code. > > > James; on a different note: > > Any contextSaves by an application or middleware will just make this > > problem appear earlier but the Kernel's RM will do the contextSave of > > A's sessions anyways. > > You can easily make the same problem appear in ANY TSS and you know > > this very well. > > So, please stop bad mouthing "not your TSS"es. > > Well, OK, how about this: there is a unique feature of the tpm tools allied with the Intel TSS in that they any use of sessions always seem to induce a session context save which can lead to a gapping problem. So in the issue linked above, the tpm2-tools are not used at all. And the tpm2-tss libraries do not do any ContextSaves on their own. So here we are hitting the issue from pure application workload. So I am glad that we agree that the kernel needs to learn how to ungap sessions.
