Re: [Ibmtpm20tss-users] [openssl-tpm2-engine] tpm sessions

Jerry Snitselaar <jsnitsel@...>

On Mon Mar 18 19, James Bottomley wrote:
On Mon, 2019-03-18 at 21:05 +0000, Doug Fraser wrote:

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?
No as I explained in the other email, the openssl_tpm2_engine mostly
keeps the TPM clear when it's not doing anything even if the key is
present and referenced from an openssl point of view.

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?
Yes, it's chip->tpm_mutex which is taken in tpm_common_write via

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.
well something caused the -EIO in tpm_try_transmit and that can only
come from the underlying driver. For the tis driver it means that
STS_DATA_EXPECT wasn't signalled as it should for transmitting data.

I wonder if this is problem I was dealing with last year where someone
had a tpm getting into a state where they were in the send codepath
and getting EIO, Debugging code added to where the expect data checks
are showed the access register reading that the locality wasn't
active, and that the status register was reading 0xff. Looking at
ftrace output was odd, because it showed it going into
release_locality, and then it would request_locality and see the
locality as active, and not try to request the locality. So a patch
went into 4.18 to change the release locality code in the tis driver
to check that the access register shows the locality as no longer
active before returning instead of returning immediately.

Doug, are you able to test a 4.18 or later kernel?


Ibmtpm20tss-users mailing list

Join to automatically receive all group messages.