Kenneth Goldman <kgoldman@...>
> From: Doug Fraser <doug.fraser@...>
> To: Kenneth Goldman <kgoldman@...>
> Cc: "Ibmtpm20tss-users@..." <Ibmtpm20tss-
> users@...>, "firstname.lastname@example.org"
> Date: 03/18/2019 03:48 PM
> Subject: 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
> 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.
14 applications ... but how many session per application?
That is, a typical operation will use 2-3 sessions - 2 for
authorization and perhaps one for audit.
If an application doesn't either explicitly flush,
or exit so that the resource manager will clean up, sessions
can hang around. Eventually the 64 session limit is reached.
If it runs for while and then fails, perhaps there is a
FWIW, when the RM was first coded, I regression tested it.
I ran 21 processes, and each created 3 session, did something,
and then flushed them, in a loop. It ran quite a while.
However, I did not test a process closing without explicitly
flushing. Should I do that?
Should I rerun the test on a newer kernel? Perhaps there
was a regression.
I.e., if I can help, let me know.