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

Doug Fraser

Jerry, if there is still some information you would like me to gather from this at the low level, let me know.

I don't know how many people are still on 4.14, but if you do back port, it will be a great help to them.
I was a little leery of the wholesale replacement with the 4.18 TPM, but I found that trying to cherry pick your changes into the 4.14 base was not as easy as I had hoped, given the difference in the underpinnings, and the rip and replace went more easily.

I tested it all day today while doing other work. Running one particular multi-thread test against the openssl engine that was resulting in sporadic timeouts at the engine layers about once every three seconds for an hour. Throughout that test, not a single low level driver error. Not one.

Then when I brought it back down to a single thread, all the timeouts ceased, and it went on its merry way.

All good.


-----Original Message-----
From: Doug Fraser
Sent: Wednesday, March 20, 2019 10:57 AM
To: 'Jerry Snitselaar' <jsnitsel@...>
Cc: James Bottomley <James.Bottomley@...>;; Kenneth Goldman <kgoldman@...>; Ibmtpm20tss-users@...
Subject: RE: [Ibmtpm20tss-users] [openssl-tpm2-engine] tpm sessions

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:


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.


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

On Tue Mar 19 19, Doug Fraser wrote:

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.


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.

-client communications.

Join to automatically receive all group messages.