Re: [Ibmtpm20tss-users] tpm sessions

Doug Fraser
 

Ken,

We are interfacing to the TPM via openssl with engine = tpm2, so at that level, do we have direct access to session control?

The test server requests openssl to encrypt a block of data, then passes it to the client. The client requests openssl to decrypt the block, and checks its content. At that point, at the application level, the transaction is complete.

Is there some other operation that the application has to request from openssl to flush the related context?

I'll go back to something James mentioned in his reply, the failure seems to be percolating up from SPI device layer.
Is there a serialization point within the SPI layer to marshal commands into and out of the TPM?

I noticed a flag based mutex() with tpm_command(), but I haven't spilled data from that yet.
Is that the serialization point for the interface?

I don't suspect signal integrity at the low clock rate we are currently running, particularly in regard to the extreme long term test that was run over the weekend.

Doug

From: Kenneth Goldman <kgoldman@...>
Sent: Monday, March 18, 2019 4:49 PM
To: Doug Fraser <doug.fraser@...>
Cc: Ibmtpm20tss-users@...; openssl-tpm2-engine@groups.io
Subject: RE: [Ibmtpm20tss-users] tpm sessions


From: Doug Fraser <doug.fraser@...<mailto:doug.fraser@...>>
To: Kenneth Goldman <kgoldman@...<mailto:kgoldman@...>>
Cc: "Ibmtpm20tss-users@...<mailto:Ibmtpm20tss-users@...>" <Ibmtpm20tss-
users@...<mailto:users@...>>, "openssl-tpm2-engine@groups.io<mailto:openssl-tpm2-engine@groups.io>"
<openssl-tpm2-engine@groups.io<mailto: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?

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
'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?

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.

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 openssl-tpm2-engine@groups.io to automatically receive all group messages.