Re: [Ibmtpm20tss-users] tpm sessions
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@...; firstname.lastname@example.org
Subject: Re: [Ibmtpm20tss-users] tpm sessions
From: Doug Fraser <doug.fraser@...<mailto:doug.fraser@...>>Background:
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
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.