Date   
Verification via public key fails...

jvert
 

Hi,

I'm able to sign using the following:

$ openssl dgst -engine tpm2 -keyform engine -sha256 -sign //nvkey:81800001 xxx >xxx.sig
engine "tpm2" set.
$ xxd xxx.sig
00000000: 3044 0220 5444 ae8c 36a1 c308 ef65 8f06 0D. TD..6....e..
00000010: e554 0e1a f136 948e eeed a6ab 5a74 c4e3 .T...6......Zt..
00000020: a717 ccac 0220 2e29 f92c 9cb3 733b b295 ..... .).,..s;..
00000030: d9cf 6fe8 b17e b1dc 00cd 3c92 fe1f d6ec ..o..~....<.....
00000040: 0b47 0448 0178 .G.H.x

What’s curious is that I’m not able to verify in a symmetric manner using the engine and the nvkey moniker:

$ openssl dgst -engine tpm2 -keyform engine -verify //nvkey:81800001 -signature xxx.sig xxx
engine "tpm2" set.
cannot load key file from engine
140075721995456:error:26097075:engine routines:ENGINE_load_public_key:not initialised:../crypto/engine/eng_pkey.c:97:
unable to load key file

I _am_ able to verify using -prverify, so it would seem that using the public key via the nvkey moniker doesn't work.

Thanks.

Re: Installing openssl_tpm2_engine-2.3.0...

James Bottomley
 

[adding the list because we actually have one now]

On Wed, 2019-05-29 at 18:48 +0000, Sievert, James wrote:
Hi James,

I've configured openssl_tpm2_engine-2.3.0<https://git.kernel.org/pub/
scm/linux/kernel/git/jejb/openssl_tpm2_engine.git/snapshot/openssl_tp
m2_engine-2.3.0.tar.gz> as follows:

CFLAGS=-I../rootfs/include LDFLAGS="-L../rootfs/lib" ./configure --
prefix=$(pwd)/../rootfs

I'm finding that "make install" doesn't abide by the --prefix option:

ubuntu@ip-10-132-42-78:~/platforms/vss/CS/Tempest/src/packages/src/Op
ensslTpm2EnginePackage/openssl_tpm2_engine-2.3.0$ make install
Making install in tests
make[1]: Entering directory
'/home/ubuntu/platforms/vss/CS/Tempest/src/packages/src/OpensslTpm2En
ginePackage/openssl_tpm2_engine-2.3.0/tests'
make[2]: Entering directory
'/home/ubuntu/platforms/vss/CS/Tempest/src/packages/src/OpensslTpm2En
ginePackage/openssl_tpm2_engine-2.3.0/tests'
make[2]: Nothing to be done for 'install-exec-am'.
make[2]: Nothing to be done for 'install-data-am'.
make[2]: Leaving directory
'/home/ubuntu/platforms/vss/CS/Tempest/src/packages/src/OpensslTpm2En
ginePackage/openssl_tpm2_engine-2.3.0/tests'
make[1]: Leaving directory
'/home/ubuntu/platforms/vss/CS/Tempest/src/packages/src/OpensslTpm2En
ginePackage/openssl_tpm2_engine-2.3.0/tests'
make[1]: Entering directory
'/home/ubuntu/platforms/vss/CS/Tempest/src/packages/src/OpensslTpm2En
ginePackage/openssl_tpm2_engine-2.3.0'
make[2]: Entering directory
'/home/ubuntu/platforms/vss/CS/Tempest/src/packages/src/OpensslTpm2En
ginePackage/openssl_tpm2_engine-2.3.0'
/bin/mkdir -p
'/home/ubuntu/platforms/vss/CS/Tempest/src/packages/src/OpensslTpm2En
ginePackage/openssl_tpm2_engine-2.3.0/../rootfs/bin'
/bin/bash ./libtool --mode=install /usr/bin/install -c
create_tpm2_key load_tpm2_key
'/home/ubuntu/platforms/vss/CS/Tempest/src/packages/src/OpensslTpm2En
ginePackage/openssl_tpm2_engine-2.3.0/../rootfs/bin'
libtool: install: /usr/bin/install -c create_tpm2_key
/home/ubuntu/platforms/vss/CS/Tempest/src/packages/src/OpensslTpm2Eng
inePackage/openssl_tpm2_engine-2.3.0/../rootfs/bin/create_tpm2_key
libtool: install: /usr/bin/install -c load_tpm2_key
/home/ubuntu/platforms/vss/CS/Tempest/src/packages/src/OpensslTpm2Eng
inePackage/openssl_tpm2_engine-2.3.0/../rootfs/bin/load_tpm2_key
/bin/mkdir -p
'/home/ubuntu/platforms/vss/CS/Tempest/src/packages/src/OpensslTpm2En
ginePackage/openssl_tpm2_engine-2.3.0/../rootfs/share/man/man1'
/usr/bin/install -c -m 644 create_tpm2_key.1 load_tpm2_key.1
'/home/ubuntu/platforms/vss/CS/Tempest/src/packages/src/OpensslTpm2En
ginePackage/openssl_tpm2_engine-2.3.0/../rootfs/share/man/man1'
/bin/mkdir -p '/usr/lib/x86_64-linux-gnu/engines-1.1'
/bin/bash ./libtool --mode=install /usr/bin/install -c libtpm2.la
'/usr/lib/x86_64-linux-gnu/engines-1.1'
libtool: install: /usr/bin/install -c .libs/libtpm2.so
/usr/lib/x86_64-linux-gnu/engines-1.1/libtpm2.so
/usr/bin/install: cannot create regular file '/usr/lib/x86_64-linux-
gnu/engines-1.1/libtpm2.so': Permission denied
Makefile:474: recipe for target 'install-openssl_engineLTLIBRARIES'
failed
make[2]: *** [install-openssl_engineLTLIBRARIES] Error 1
make[2]: Leaving directory
'/home/ubuntu/platforms/vss/CS/Tempest/src/packages/src/OpensslTpm2En
ginePackage/openssl_tpm2_engine-2.3.0'
Makefile:1046: recipe for target 'install-am' failed
make[1]: *** [install-am] Error 2
make[1]: Leaving directory
'/home/ubuntu/platforms/vss/CS/Tempest/src/packages/src/OpensslTpm2En
ginePackage/openssl_tpm2_engine-2.3.0'
Makefile:745: recipe for target 'install-recursive' failed
make: *** [install-recursive] Error 1
Got to confess, this isn't something I've tried directly (so I will
test it out and see what the problem is). However, both the openSUSE
and debian packages which are built from this, use the --prefix option
in some form and they all seem to install correctly, so there's
something different about the way you did it that I'll have to figure
out.

James

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

Jerry Snitselaar <jsnitsel@...>
 

On Mon Mar 25 19, Doug Fraser wrote:

Jerry,

I captured the following out of order. You added line is the first emitted at the time of the fault.

/var/log/messages:Mar 25 13:28:27 C05BUB0000A000004124 kern.info kernel: [ 1461.843825] tpm tpm0: tpm_tis_send_data: TPM_STS_DATA_EXPECT == 0: locality: 0 status: ff access: 81
Yes, that was what was being seen before with the registers. The
access register says it has a valid status and it is saying the
locality is not active. I've been dragged into another issue, so I
haven't been able to deal with backporting the patch to 4.14. It
should be straightforward, the only difference that I think needs to
be dealt with is the fact the release_locality has a void return
instead of int. I will hopefully get to it in the next couple of days.


/var/log/messages:Mar 25 13:28:27 C05BUB0000A000004124 kern.err kernel: [ 1461.858321] tpm tpm0: tpm_try_transmit: tpm_send: error -5
/var/log/messages:Mar 25 13:28:27 C05BUB0000A000004124 kern.err kernel: [ 1461.865369] tpm tpm0: A TPM error (357) occurred flushing context

Note also that the 4.18 TPM pull into my 4.14 kernel continues to perform well.

Doug

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

Doug Fraser
 

Jerry,

I captured the following out of order. You added line is the first emitted at the time of the fault.

/var/log/messages:Mar 25 13:28:27 C05BUB0000A000004124 kern.info kernel: [ 1461.843825] tpm tpm0: tpm_tis_send_data: TPM_STS_DATA_EXPECT == 0: locality: 0 status: ff access: 81


/var/log/messages:Mar 25 13:28:27 C05BUB0000A000004124 kern.err kernel: [ 1461.858321] tpm tpm0: tpm_try_transmit: tpm_send: error -5
/var/log/messages:Mar 25 13:28:27 C05BUB0000A000004124 kern.err kernel: [ 1461.865369] tpm tpm0: A TPM error (357) occurred flushing context

Note also that the 4.18 TPM pull into my 4.14 kernel continues to perform well.

Doug

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

Jerry Snitselaar <jsnitsel@...>
 

On Wed Mar 20 19, Doug Fraser wrote:
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.

Doug

-----Original Message-----
From: Doug Fraser
Sent: Wednesday, March 20, 2019 10:57 AM
To: 'Jerry Snitselaar' <jsnitsel@...>
Cc: James Bottomley <James.Bottomley@...>; openssl-tpm2-engine@groups.io; 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:

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
-client communications.
Hi Doug,

Here is a debug patch against the 4.14.y rpi branch to dump the access and status registers when
the status data expect checks fail. I'm starting on backporting the release locality patch now.

--8<--

diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index 63bc6c3b949e..7c0394765aea 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 *buf, size_t len)
int rc, status, burstcnt;
size_t count = 0;
bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND;
+ u8 access;

status = tpm_tis_status(chip);
if ((status & TPM_STS_COMMAND_READY) == 0) {
@@ -292,6 +293,13 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 *buf, size_t len)
}
status = tpm_tis_status(chip);
if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
+ rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access);
+ if (rc < 0)
+ dev_info(&chip->dev, "%s: TPM_STS_DATA_EXPECT == 0: read failure TPM_ACCESS(%d)\n",
+ __func__, priv->locality);
+ else
+ dev_info(&chip->dev, "%s: TPM_STS_DATA_EXPECT == 0: locality: %d status: %x access: %x\n",
+ __func__, priv->locality, status, access);
rc = -EIO;
goto out_err;
}
@@ -309,6 +317,13 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 *buf, size_t len)
}
status = tpm_tis_status(chip);
if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) {
+ rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access);
+ if (rc < 0)
+ dev_info(&chip->dev, "%s: TPM_STS_DATA_EXPECT != 0: read failure TPM_ACCESS(%d)\n",
+ __func__, priv->locality);
+ else
+ dev_info(&chip->dev, "%s: TPM_STS_DATA_EXPECT != 0: locality: %d status: %x access: %x\n",
+ __func__, priv->locality, status, access);
rc = -EIO;
goto out_err;
}
--
2.21.0

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

Doug Fraser
 

Gave your patch a shot against my 4.14 (with no other patches)
Last line is your addition.

/var/log/messages:Mar 25 13:28:27 C05BUB0000A000004124 kern.err kernel: [ 1461.858321] tpm tpm0: tpm_try_transmit: tpm_send: error -5
/var/log/messages:Mar 25 13:28:27 C05BUB0000A000004124 kern.err kernel: [ 1461.865369] tpm tpm0: A TPM error (357) occurred flushing context
/var/log/messages:Mar 25 13:28:27 C05BUB0000A000004124 kern.info kernel: [ 1461.873871] tpm tpm0: tpm_tis_send_data: TPM_STS_DATA_EXPECT == 0: locality: 0 status: ff access: 81

-----Original Message-----
From: Jerry Snitselaar <jsnitsel@...>
Sent: Wednesday, March 20, 2019 4:37 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 Wed Mar 20 19, Doug Fraser wrote:
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.

Doug

-----Original Message-----
From: Doug Fraser
Sent: Wednesday, March 20, 2019 10:57 AM
To: 'Jerry Snitselaar' <jsnitsel@...>
Cc: James Bottomley <James.Bottomley@...>;
openssl-tpm2-engine@groups.io; 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:

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
-client communications.
Hi Doug,

Here is a debug patch against the 4.14.y rpi branch to dump the access and status registers when the status data expect checks fail. I'm starting on backporting the release locality patch now.

--8<--

diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c index 63bc6c3b949e..7c0394765aea 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -258,6 +258,7 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 *buf, size_t len)
int rc, status, burstcnt;
size_t count = 0;
bool itpm = priv->flags & TPM_TIS_ITPM_WORKAROUND;
+ u8 access;

status = tpm_tis_status(chip);
if ((status & TPM_STS_COMMAND_READY) == 0) { @@ -292,6 +293,13 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 *buf, size_t len)
}
status = tpm_tis_status(chip);
if (!itpm && (status & TPM_STS_DATA_EXPECT) == 0) {
+ rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access);
+ if (rc < 0)
+ dev_info(&chip->dev, "%s: TPM_STS_DATA_EXPECT == 0: read failure TPM_ACCESS(%d)\n",
+ __func__, priv->locality);
+ else
+ dev_info(&chip->dev, "%s: TPM_STS_DATA_EXPECT == 0: locality: %d status: %x access: %x\n",
+ __func__, priv->locality, status, access);
rc = -EIO;
goto out_err;
}
@@ -309,6 +317,13 @@ static int tpm_tis_send_data(struct tpm_chip *chip, u8 *buf, size_t len)
}
status = tpm_tis_status(chip);
if (!itpm && (status & TPM_STS_DATA_EXPECT) != 0) {
+ rc = tpm_tis_read8(priv, TPM_ACCESS(priv->locality), &access);
+ if (rc < 0)
+ dev_info(&chip->dev, "%s: TPM_STS_DATA_EXPECT != 0: read failure TPM_ACCESS(%d)\n",
+ __func__, priv->locality);
+ else
+ dev_info(&chip->dev, "%s: TPM_STS_DATA_EXPECT != 0: locality: %d status: %x access: %x\n",
+ __func__, priv->locality, status, access);
rc = -EIO;
goto out_err;
}
--
2.21.0


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.

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.

Doug

-----Original Message-----
From: Doug Fraser
Sent: Wednesday, March 20, 2019 10:57 AM
To: 'Jerry Snitselaar' <jsnitsel@...>
Cc: James Bottomley <James.Bottomley@...>; openssl-tpm2-engine@groups.io; 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:

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
-client communications.

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.

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

Jerry Snitselaar <jsnitsel@...>
 

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

Was there anything outside of drivers/char/tpm tree?

I diffed that whole tree 4.14 vs 4.18 and got a small number of diffs.

Doug

These five files...

diff --unified --recursive --minimal a/linux/drivers/char/tpm/Kconfig b/linux/drivers/char/tpm/Kconfig
diff --unified --recursive --minimal a/linux/drivers/char/tpm/tpm_crb.c b/linux/drivers/char/tpm/tpm_crb.c
diff --unified --recursive --minimal a/linux/drivers/char/tpm/tpm_i2c_nuvoton.c b/linux/drivers/char/tpm/tpm_i2c_nuvoton.c
diff --unified --recursive --minimal a/linux/drivers/char/tpm/tpm-interface.c b/linux/drivers/char/tpm/tpm-interface.c
diff --unified --recursive --minimal a/linux/drivers/char/tpm/xen-tpmfront.c b/linux/drivers/char/tpm/xen-tpmfront.c
I went back through the email chain again, and it looked like you were
running the tis driver with spi. Is that correct?


With what looks to be the relevant changes in tpm-interface.c, with about a dozen lines spread across five sections of code.

diff --unified --recursive --minimal a/linux/drivers/char/tpm/tpm-interface.c b/linux/drivers/char/tpm/tpm-interface.c
--- a/linux/drivers/char/tpm/tpm-interface.c 2019-02-25 12:55:59.000000000 -0500
+++ b/linux/drivers/char/tpm/tpm-interface.c 2019-03-19 09:36:57.601582514 -0400
@@ -479,13 +479,15 @@

if (need_locality) {
rc = tpm_request_locality(chip, flags);
- if (rc < 0)
- goto out_no_locality;
+ if (rc < 0) {
+ need_locality = false;
+ goto out_locality;
+ }
}

rc = tpm_cmd_ready(chip, flags);
if (rc)
- goto out;
+ goto out_locality;

rc = tpm2_prepare_space(chip, space, ordinal, buf);
if (rc)
@@ -549,14 +551,13 @@
dev_err(&chip->dev, "tpm2_commit_space: error %d\n", rc);

out:
- rc = tpm_go_idle(chip, flags);
- if (rc)
- goto out;
+ /* may fail but do not override previous error value in rc */
+ tpm_go_idle(chip, flags);

+out_locality:
if (need_locality)
tpm_relinquish_locality(chip, flags);

-out_no_locality:
if (chip->ops->clk_enable != NULL)
chip->ops->clk_enable(chip, false);

@@ -611,12 +612,13 @@
rc = be32_to_cpu(header->return_code);
if (rc != TPM2_RC_RETRY)
break;
- delay_msec *= 2;
+
if (delay_msec > TPM2_DURATION_LONG) {
dev_err(&chip->dev, "TPM is in retry loop\n");
break;
}
tpm_msleep(delay_msec);
+ delay_msec *= 2;
memcpy(buf, save, save_size);
}
return ret;
@@ -652,7 +654,8 @@
return len;

err = be32_to_cpu(header->return_code);
- if (err != 0 && desc)
+ if (err != 0 && err != TPM_ERR_DISABLED && err != TPM_ERR_DEACTIVATED
+ && desc)
dev_err(&chip->dev, "A TPM error (%d) occurred %s\n", err,
desc);
if (err)

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

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

Doug Fraser
 

Ah, sorry, yes we are using the TIS driver

tpm_tis_spi 16384 0
tpm_tis_core 20480 1 tpm_tis_spi
tpm 57344 18 tpm_tis_spi,tpm_tis_core

I was just showing all the diffs that showed up in drivers/char/tpm

It seemed the most interesting (to us) would be in linux/drivers/char/tpm/tpm-interface.c

Is that not used in TIS? I didn't capture any other diffs.


Doug

-----Original Message-----
From: Jerry Snitselaar <jsnitsel@...>
Sent: Tuesday, March 19, 2019 1:52 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, 2019 at 10:43 AM Doug Fraser <doug.fraser@...> wrote:

Jerry,

Was there anything outside of drivers/char/tpm tree?

I diffed that whole tree 4.14 vs 4.18 and got a small number of diffs.

Doug

These five files...

diff --unified --recursive --minimal a/linux/drivers/char/tpm/Kconfig
b/linux/drivers/char/tpm/Kconfig diff --unified --recursive --minimal
a/linux/drivers/char/tpm/tpm_crb.c b/linux/drivers/char/tpm/tpm_crb.c
diff --unified --recursive --minimal
a/linux/drivers/char/tpm/tpm_i2c_nuvoton.c
b/linux/drivers/char/tpm/tpm_i2c_nuvoton.c
diff --unified --recursive --minimal
a/linux/drivers/char/tpm/tpm-interface.c
b/linux/drivers/char/tpm/tpm-interface.c
diff --unified --recursive --minimal
a/linux/drivers/char/tpm/xen-tpmfront.c
b/linux/drivers/char/tpm/xen-tpmfront.c

With what looks to be the relevant changes in tpm-interface.c, with about a dozen lines spread across five sections of code.
I somehow got it in my mind reading this earlier that you were using the tis driver. My apologies on that, ignore the 4.18 suggestion then.
So you are using
tpm_i2c_nuvoton and the crb driver?



diff --unified --recursive --minimal a/linux/drivers/char/tpm/tpm-interface.c b/linux/drivers/char/tpm/tpm-interface.c
--- a/linux/drivers/char/tpm/tpm-interface.c 2019-02-25 12:55:59.000000000 -0500
+++ b/linux/drivers/char/tpm/tpm-interface.c 2019-03-19 09:36:57.601582514 -0400
@@ -479,13 +479,15 @@

if (need_locality) {
rc = tpm_request_locality(chip, flags);
- if (rc < 0)
- goto out_no_locality;
+ if (rc < 0) {
+ need_locality = false;
+ goto out_locality;
+ }
}

rc = tpm_cmd_ready(chip, flags);
if (rc)
- goto out;
+ goto out_locality;

rc = tpm2_prepare_space(chip, space, ordinal, buf);
if (rc)
@@ -549,14 +551,13 @@
dev_err(&chip->dev, "tpm2_commit_space: error %d\n",
rc);

out:
- rc = tpm_go_idle(chip, flags);
- if (rc)
- goto out;
+ /* may fail but do not override previous error value in rc */
+ tpm_go_idle(chip, flags);

+out_locality:
if (need_locality)
tpm_relinquish_locality(chip, flags);

-out_no_locality:
if (chip->ops->clk_enable != NULL)
chip->ops->clk_enable(chip, false);

@@ -611,12 +612,13 @@
rc = be32_to_cpu(header->return_code);
if (rc != TPM2_RC_RETRY)
break;
- delay_msec *= 2;
+
if (delay_msec > TPM2_DURATION_LONG) {
dev_err(&chip->dev, "TPM is in retry loop\n");
break;
}
tpm_msleep(delay_msec);
+ delay_msec *= 2;
memcpy(buf, save, save_size);
}
return ret;
@@ -652,7 +654,8 @@
return len;

err = be32_to_cpu(header->return_code);
- if (err != 0 && desc)
+ if (err != 0 && err != TPM_ERR_DISABLED && err != TPM_ERR_DEACTIVATED
+ && desc)
dev_err(&chip->dev, "A TPM error (%d) occurred %s\n", err,
desc);
if (err)

-----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
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.

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

Jerry Snitselaar <jsnitsel@...>
 

On Tue, Mar 19, 2019 at 10:43 AM Doug Fraser <doug.fraser@...> wrote:

Jerry,

Was there anything outside of drivers/char/tpm tree?

I diffed that whole tree 4.14 vs 4.18 and got a small number of diffs.

Doug

These five files...

diff --unified --recursive --minimal a/linux/drivers/char/tpm/Kconfig b/linux/drivers/char/tpm/Kconfig
diff --unified --recursive --minimal a/linux/drivers/char/tpm/tpm_crb.c b/linux/drivers/char/tpm/tpm_crb.c
diff --unified --recursive --minimal a/linux/drivers/char/tpm/tpm_i2c_nuvoton.c b/linux/drivers/char/tpm/tpm_i2c_nuvoton.c
diff --unified --recursive --minimal a/linux/drivers/char/tpm/tpm-interface.c b/linux/drivers/char/tpm/tpm-interface.c
diff --unified --recursive --minimal a/linux/drivers/char/tpm/xen-tpmfront.c b/linux/drivers/char/tpm/xen-tpmfront.c

With what looks to be the relevant changes in tpm-interface.c, with about a dozen lines spread across five sections of code.
I somehow got it in my mind reading this earlier that you were using
the tis driver. My apologies on that, ignore the 4.18 suggestion then.
So you are using
tpm_i2c_nuvoton and the crb driver?



diff --unified --recursive --minimal a/linux/drivers/char/tpm/tpm-interface.c b/linux/drivers/char/tpm/tpm-interface.c
--- a/linux/drivers/char/tpm/tpm-interface.c 2019-02-25 12:55:59.000000000 -0500
+++ b/linux/drivers/char/tpm/tpm-interface.c 2019-03-19 09:36:57.601582514 -0400
@@ -479,13 +479,15 @@

if (need_locality) {
rc = tpm_request_locality(chip, flags);
- if (rc < 0)
- goto out_no_locality;
+ if (rc < 0) {
+ need_locality = false;
+ goto out_locality;
+ }
}

rc = tpm_cmd_ready(chip, flags);
if (rc)
- goto out;
+ goto out_locality;

rc = tpm2_prepare_space(chip, space, ordinal, buf);
if (rc)
@@ -549,14 +551,13 @@
dev_err(&chip->dev, "tpm2_commit_space: error %d\n", rc);

out:
- rc = tpm_go_idle(chip, flags);
- if (rc)
- goto out;
+ /* may fail but do not override previous error value in rc */
+ tpm_go_idle(chip, flags);

+out_locality:
if (need_locality)
tpm_relinquish_locality(chip, flags);

-out_no_locality:
if (chip->ops->clk_enable != NULL)
chip->ops->clk_enable(chip, false);

@@ -611,12 +612,13 @@
rc = be32_to_cpu(header->return_code);
if (rc != TPM2_RC_RETRY)
break;
- delay_msec *= 2;
+
if (delay_msec > TPM2_DURATION_LONG) {
dev_err(&chip->dev, "TPM is in retry loop\n");
break;
}
tpm_msleep(delay_msec);
+ delay_msec *= 2;
memcpy(buf, save, save_size);
}
return ret;
@@ -652,7 +654,8 @@
return len;

err = be32_to_cpu(header->return_code);
- if (err != 0 && desc)
+ if (err != 0 && err != TPM_ERR_DISABLED && err != TPM_ERR_DEACTIVATED
+ && desc)
dev_err(&chip->dev, "A TPM error (%d) occurred %s\n", err,
desc);
if (err)

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

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

Doug Fraser
 

Jerry,

Was there anything outside of drivers/char/tpm tree?

I diffed that whole tree 4.14 vs 4.18 and got a small number of diffs.

Doug

These five files...

diff --unified --recursive --minimal a/linux/drivers/char/tpm/Kconfig b/linux/drivers/char/tpm/Kconfig
diff --unified --recursive --minimal a/linux/drivers/char/tpm/tpm_crb.c b/linux/drivers/char/tpm/tpm_crb.c
diff --unified --recursive --minimal a/linux/drivers/char/tpm/tpm_i2c_nuvoton.c b/linux/drivers/char/tpm/tpm_i2c_nuvoton.c
diff --unified --recursive --minimal a/linux/drivers/char/tpm/tpm-interface.c b/linux/drivers/char/tpm/tpm-interface.c
diff --unified --recursive --minimal a/linux/drivers/char/tpm/xen-tpmfront.c b/linux/drivers/char/tpm/xen-tpmfront.c

With what looks to be the relevant changes in tpm-interface.c, with about a dozen lines spread across five sections of code.

diff --unified --recursive --minimal a/linux/drivers/char/tpm/tpm-interface.c b/linux/drivers/char/tpm/tpm-interface.c
--- a/linux/drivers/char/tpm/tpm-interface.c 2019-02-25 12:55:59.000000000 -0500
+++ b/linux/drivers/char/tpm/tpm-interface.c 2019-03-19 09:36:57.601582514 -0400
@@ -479,13 +479,15 @@

if (need_locality) {
rc = tpm_request_locality(chip, flags);
- if (rc < 0)
- goto out_no_locality;
+ if (rc < 0) {
+ need_locality = false;
+ goto out_locality;
+ }
}

rc = tpm_cmd_ready(chip, flags);
if (rc)
- goto out;
+ goto out_locality;

rc = tpm2_prepare_space(chip, space, ordinal, buf);
if (rc)
@@ -549,14 +551,13 @@
dev_err(&chip->dev, "tpm2_commit_space: error %d\n", rc);

out:
- rc = tpm_go_idle(chip, flags);
- if (rc)
- goto out;
+ /* may fail but do not override previous error value in rc */
+ tpm_go_idle(chip, flags);

+out_locality:
if (need_locality)
tpm_relinquish_locality(chip, flags);

-out_no_locality:
if (chip->ops->clk_enable != NULL)
chip->ops->clk_enable(chip, false);

@@ -611,12 +612,13 @@
rc = be32_to_cpu(header->return_code);
if (rc != TPM2_RC_RETRY)
break;
- delay_msec *= 2;
+
if (delay_msec > TPM2_DURATION_LONG) {
dev_err(&chip->dev, "TPM is in retry loop\n");
break;
}
tpm_msleep(delay_msec);
+ delay_msec *= 2;
memcpy(buf, save, save_size);
}
return ret;
@@ -652,7 +654,8 @@
return len;

err = be32_to_cpu(header->return_code);
- if (err != 0 && desc)
+ if (err != 0 && err != TPM_ERR_DISABLED && err != TPM_ERR_DEACTIVATED
+ && desc)
dev_err(&chip->dev, "A TPM error (%d) occurred %s\n", err,
desc);
if (err)

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

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

Jerry Snitselaar <jsnitsel@...>
 

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.

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

Doug Fraser
 

Jerry,

We are on 4.14.77

I will look at cherry picking the tpm from 4.18

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.

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:
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

Re: [Ibmtpm20tss-users] tpm sessions

James Bottomley
 

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

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.



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.

Re: [Ibmtpm20tss-users] tpm sessions

Kenneth Goldman <kgoldman@...>
 


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

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.

Re: [Ibmtpm20tss-users] tpm sessions

Doug Fraser
 

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.

I am currently rerunning with three active test threads, and so far that has issued about twice the number of openssl engine calls without leading to any failures. If that is still running error free at the end of my day, I am going to let it run through the night. If that runs without error, I am going to binary search between 3 and 7 to see if there is a 'cliff'

Thanks again for the high level view of the numbers and limitations coming into play.

Doug


From: Kenneth Goldman <kgoldman@...>
Sent: Monday, March 18, 2019 2:34 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: "openssl-tpm2-engine@groups.io<mailto:openssl-tpm2-engine@groups.io>" <openssl-tpm2-engine@groups.io<mailto:openssl-tpm2-engine@groups.io>>,
Doug Fraser <doug.fraser@...<mailto:doug.fraser@...>>, "Ibmtpm20tss-
users@...<mailto:users@...>" <Ibmtpm20tss-users@...<mailto:Ibmtpm20tss-users@...>>
Date: 03/18/2019 02:19 PM
Subject: [Ibmtpm20tss-users] tpm sessions

So we have moved beyond the signaling issues on our TPM for now, but
in ramping up performance saturation testing, I am pounding on the
openssl engine with multiple threads of execution, and I am finding
this fault.

/var/log/messages:Mar 18 16:43:28 C05BCB00C0A000001153 kern.err
kernel: [11840.869864] tpm tpm0: tpm_try_transmit: tpm_send: error -5
/var/log/messages:Mar 18 16:43:28 C05BCB00C0A000001153 kern.err
kernel: [11840.878969] tpm tpm0: A TPM error (357) occurred flushing context

Within the kernel, reflect up through the applications as:

TPM2_StartAuthSession failed with 2309
TPM_RC_SESSION_HANDLES - out of session handles - a session must be
flushed before a new session may be created
Failed to get Key Handle in TPM EC key routines

The underlying tss code is build with:

CCFLAGS += -DTPM_POSIX \
-DTPM_INTERFACE_TYPE_DEFAULT="\"dev\"" \
-DTPM_DEVICE_DEFAULT="\"/dev/tpmrm0\"" \
$(BLD_SYSROOT)

So we should be using the tpmrm resource manager within the kernel.

If I run the test code as a single instance, this never occurs
(within the bounds of 64 hours of constant running)

Is there a practical limit to the openssl engine, underlying tpmrm,
or even the underlying physical block that I am ignoring here?
My view was that as long as you pass through the tpmrm, you might
stall, but the resources would be managed.
Background:

Sessions are different from keys, in that the TPM has to prevent a
replay attack on a saved session context. To do this, the TPM has a
table of active session contexts with a 'version number' to detect and
block the replay.

In TCG jargon (if I have it right):

A loaded session is actually on the TPM.
A saved session is off the TPM, but is still in the table.
An active session is either loaded or saved.

Result:

The table has typically 64 entries for active sessions. Thus,
threads cannot make an unlimited number of sessions, even with
a resource manager.

Again typically, an application needs at most 3 sessions, so
the TPM can handle 21 simultaneous applications.

Keys:

Since keys are not subject to a replay attack, the TPM does not
keep any state when a key is context saved. There is thus
no TPM defined limit to the number of saved key contexts.


I am going back to dig through tpm-tis, in particular, tpm2-cmd.c
and tpm-interface.c.

Doug

_______________________________________________
Ibmtpm20tss-users mailing list
Ibmtpm20tss-users@...<mailto:Ibmtpm20tss-users@...>
https://urldefense.proofpoint.com/v2/url?
u=https-3A__lists.sourceforge.net_lists_listinfo_ibmtpm20tss-2Dusers&d=DwICAg&c=jf_iaSHvJObTbx-
siA1ZOg&r=DZCVG43VcL8GTneMZb8k8lEwb-O1GZktFfre1-
mlmiA&m=XmhnfVlfhSYHtZr6FrXKzEkZPZOJHo_STtu4jislJQE&s=Fs921riOnezqzdagg8OMOP8iqow-
oOAQI5B0wwzwq2M&e=

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.