RE: TPM resource manager returns -1 for TPM2_RC_CONTEXT_GAP

[<Andreas.Fuchs@infineon.com>]

From: James Bottomley <James.Bottomley@HansenPartnership.com> 
> On Thu, 2023-10-19 at 16:16 +0000, Andreas.Fuchs@infineon.com wrote:
> > > From: James Bottomley <James.Bottomley@HansenPartnership.com>
> > > 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.