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

Doug Fraser
 

Hello All,

Last night I completely pulled 4.18 TPM into 4.14 base that we are running.

This required a couple file changes up in include/linux as well as pulling the tpm_hwrng compilation from:

linux/drivers/char/hw_random/Makefile

I need to test to see if the hw_rng (which is now instantiated in the TPM driver) is still functioning properly.

I now longer get the '-5' errors from tpm_send()

Totally gone.

Also, If I pound on the openssl engine really really really hard (really hard) I get timeouts, but the chip is just fine, and if I halt the test load, and restart with a single thread, it comes up fine. On the old driver code base (from 4.14) after a couple tpm_send() failures, the device was toast, and I had to unload, strobe the reset line, and reload the tpm driver to make it usable again. That failure mode is now longer occurring.

So pulling in 4.18 TPM took a little effort, but I am getting an error free build that brings up the TPM and is not throwing the tpm_send errors that it was throwing before.

I have a giant diff file that performs all the work on a 4.14 base to bring it up, so I can just run it as a patch against a 4.14 pull and it all builds.

Thanks to all for your support and feedback.
A special shout out to Jerry for picking up on that patch.

Doug

-----Original Message-----
From: Jerry Snitselaar <jsnitsel@...>
Sent: Tuesday, March 19, 2019 1:31 PM
To: Doug Fraser <doug.fraser@...>
Cc: James Bottomley <James.Bottomley@...>; openssl-tpm2-engine@groups.io; Kenneth Goldman <kgoldman@...>; Ibmtpm20tss-users@...
Subject: Re: [Ibmtpm20tss-users] [openssl-tpm2-engine] tpm sessions

On Tue Mar 19 19, Doug Fraser wrote:
Jerry,

We are on 4.14.77

I will look at cherry picking the tpm from 4.18
I'll take a stab at backporting the commit to 4.14 this afternoon. There are some minor differences back then, but it shouldn't too bad. Since it sounds like you are building the kernel, I can also send along a debugging patch that will spit out the values in the access and status registers when the status expect data check fails.

Regards,
Jerry


We are currently on Alpine 3.8 hoping to move to 3.9 (for other reasons) and also looking to move to 4.19 kernel.
This is going to take some time, but now I have a greater incentive to push on that.

Thank you all for your help in this.

Doug

-----Original Message-----
From: Jerry Snitselaar <jsnitsel@...>
Sent: Tuesday, March 19, 2019 12:07 AM
To: James Bottomley <James.Bottomley@...>
Cc: openssl-tpm2-engine@groups.io; Doug Fraser <doug.fraser@...>;
Kenneth Goldman <kgoldman@...>;
Ibmtpm20tss-users@...
Subject: Re: [Ibmtpm20tss-users] [openssl-tpm2-engine] tpm sessions

On Mon Mar 18 19, James Bottomley wrote:
On Mon, 2019-03-18 at 21:05 +0000, Doug Fraser wrote:
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?
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
tpm_try_get_ops.

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.

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

Regards,
Jerry



_______________________________________________
Ibmtpm20tss-users mailing list
Ibmtpm20tss-users@...
https://lists.sourceforge.net/lists/listinfo/ibmtpm20tss-users
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.
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.