Re: [Ibmtpm20tss-users] tpm sessions

Doug Fraser


Thank you for that information.

I don't believe we should be exceeded that limit.

The nature of the test is that each thread spawns a shell that invokes a client/server pair that each use openssl (and the tpm2 engine) to trade a piece of data. One side is encrypting, the other decrypting.

So for any given thread, there are two processes, that both completely exit and then the shell terminates, and the process repeats, with a new shell invocation.

So for seven test threads, worst case is 2 * 7 simultaneous applications active (14) which seems safely less than 21.

I am currently rerunning with three active test threads, and so far that has issued about twice the number of openssl engine calls without leading to any failures. If that is still running error free at the end of my day, I am going to let it run through the night. If that runs without error, I am going to binary search between 3 and 7 to see if there is a 'cliff'

Thanks again for the high level view of the numbers and limitations coming into play.


From: Kenneth Goldman <kgoldman@...>
Sent: Monday, March 18, 2019 2:34 PM
To: Doug Fraser <doug.fraser@...>
Cc: Ibmtpm20tss-users@...;
Subject: Re: [Ibmtpm20tss-users] tpm sessions

From: Doug Fraser <doug.fraser@...<mailto:doug.fraser@...>>
To: "<>" <<>>,
Doug Fraser <doug.fraser@...<mailto:doug.fraser@...>>, "Ibmtpm20tss-
users@...<mailto:users@...>" <Ibmtpm20tss-users@...<mailto: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_DEVICE_DEFAULT="\"/dev/tpmrm0\"" \

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.


Ibmtpm20tss-users mailing list

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient:(a) any dissemination or copying of this message is strictly prohibited; and (b) immediately notify the sender by return message and destroy any copies of this message in any form (electronic, paper or otherwise) that you have. The delivery of this message and its information is neither intended to be nor constitutes a disclosure or waiver of any trade secrets, intellectual property, attorney work product, or attorney-client communications.

Join to automatically receive all group messages.