Re: [Ibmtpm20tss-users] tpm sessions

James Bottomley
 

On Mon, 2019-03-18 at 15:48 -0500, Kenneth Goldman wrote:
From: Doug Fraser <doug.fraser@...>
To: Kenneth Goldman <kgoldman@...>
Cc: "Ibmtpm20tss-users@..." <Ibmtpm20tss-
users@...>, "openssl-tpm2-engine@groups.io"
<openssl-tpm2-engine@groups.io>
Date: 03/18/2019 03:48 PM
Subject: RE: [Ibmtpm20tss-users] tpm sessions

Ken,

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.
14 applications ... but how many session per application?
The openssl_tpm2_engine typically only uses 1 session for each command.
We use the same session for hmac and decryption and we don't run
audits. I think all of the commands we use only require at most one
authorization. We also don't keep sessions loaded, so every time you
use the key, we go through a start session/load key/do key op/flush
handles sequence.

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.
There's another possibility as well, which is that an application that
keeps a session for a long time can cause a gap error (the TPM doesn't
allow session sequence numbers to wrap around).

However, openssl_tpm2_engine was coded with the old /dev/tpm0 interface
in mind, so it tries to keep the session and volatile handle use
periods as short as possible.

If it runs for while and then fails, perhaps there is a
'session leak'?

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?
We should already have tested that, but there's no harm in making sure.
The current smoke tests are in the kernel under
tools/testing/selftests/tpm2

James


Doug, James:

Should I rerun the test on a newer kernel? Perhaps there
was a regression.

I.e., if I can help, let me know.



Join openssl-tpm2-engine@groups.io to automatically receive all group messages.