Re: [Ibmtpm20tss-users] tpm sessions

Kenneth Goldman <kgoldman@...>

> From: Doug Fraser <doug.fraser@...>
> To: "" <>,
> Doug Fraser <doug.fraser@...>, "Ibmtpm20tss-
> users@..." <Ibmtpm20tss-users@...>

> Date: 03/18/2019 02:19 PM
> Subject: [Ibmtpm20tss-users] tpm sessions
> So we have moved beyond the signaling issues on our TPM for now, but
> in ramping up performance saturation testing, I am pounding on the
> openssl engine with multiple threads of execution, and I am finding
> this fault.
> /var/log/messages:Mar 18 16:43:28 C05BCB00C0A000001153 kern.err
> kernel: [11840.869864] tpm tpm0: tpm_try_transmit: tpm_send: error -5
> /var/log/messages:Mar 18 16:43:28 C05BCB00C0A000001153 kern.err
> kernel: [11840.878969] tpm tpm0: A TPM error (357) occurred flushing context
> Within the kernel, reflect up through the applications as:
> TPM2_StartAuthSession failed with 2309
> TPM_RC_SESSION_HANDLES - out of session handles - a session must be
> flushed before a new session may be created
> Failed to get Key Handle in TPM EC key routines
> The underlying tss code is build with:
>         -DTPM_INTERFACE_TYPE_DEFAULT="\"dev\""  \
>         -DTPM_DEVICE_DEFAULT="\"/dev/tpmrm0\"" \
>         $(BLD_SYSROOT)
> So we should be using the tpmrm  resource manager within the kernel.
> If I run the test code as a single instance, this never occurs
> (within the bounds of 64 hours of constant running)
> Is there a practical limit to the openssl engine, underlying tpmrm,
> or even the underlying physical block that I am ignoring here?
> My view was that as long as you pass through the tpmrm, you might
> stall, but the resources would be managed.


Sessions are different from keys, in that the TPM has to prevent a
replay attack on a saved session context. To do this, the TPM has a
table of active session contexts with a 'version number' to detect and
block the replay.

In TCG jargon (if I have it right):

A loaded session is actually on the TPM.
A saved session is off the TPM, but is still in the table.
An active session is either loaded or saved.


The table has typically 64 entries for active sessions.  Thus,
threads cannot make an unlimited number of sessions, even with
a resource manager.

Again typically, an application needs at most 3 sessions, so
the TPM can handle 21 simultaneous applications.


Since keys are not subject to a replay attack, the TPM does not
keep any state when a key is context saved.  There is thus
no TPM defined limit to the number of saved key contexts.

> I am going back to dig through tpm-tis, in particular, tpm2-cmd.c
> and tpm-interface.c.
> Doug
> _______________________________________________
> Ibmtpm20tss-users mailing list
> Ibmtpm20tss-users@...
> u=https-3A__lists.sourceforge.net_lists_listinfo_ibmtpm20tss-2Dusers&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-
> mlmiA&m=XmhnfVlfhSYHtZr6FrXKzEkZPZOJHo_STtu4jislJQE&s=Fs921riOnezqzdagg8OMOP8iqow-
> oOAQI5B0wwzwq2M&e=

Join to automatically receive all group messages.