<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/char/tpm, branch v5.17</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>tpm: fix NPE on probe for missing device</title>
<updated>2022-01-08T22:18:51+00:00</updated>
<author>
<name>Patrick Williams</name>
<email>patrick@stwcx.xyz</email>
</author>
<published>2021-12-23T15:49:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=84cc69589700b90a4c8d27b481a51fce8cca6051'/>
<id>84cc69589700b90a4c8d27b481a51fce8cca6051</id>
<content type='text'>
When using the tpm_tis-spi driver on a system missing the physical TPM,
a null pointer exception was observed.

    [    0.938677] Unable to handle kernel NULL pointer dereference at virtual address 00000004
    [    0.939020] pgd = 10c753cb
    [    0.939237] [00000004] *pgd=00000000
    [    0.939808] Internal error: Oops: 5 [#1] SMP ARM
    [    0.940157] CPU: 0 PID: 48 Comm: kworker/u4:1 Not tainted 5.15.10-dd1e40c #1
    [    0.940364] Hardware name: Generic DT based system
    [    0.940601] Workqueue: events_unbound async_run_entry_fn
    [    0.941048] PC is at tpm_tis_remove+0x28/0xb4
    [    0.941196] LR is at tpm_tis_core_init+0x170/0x6ac

This is due to an attempt in 'tpm_tis_remove' to use the drvdata, which
was not initialized in 'tpm_tis_core_init' prior to the first error.

Move the initialization of drvdata earlier so 'tpm_tis_remove' has
access to it.

Signed-off-by: Patrick Williams &lt;patrick@stwcx.xyz&gt;
Fixes: 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries")
Cc: stable@vger.kernel.org
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When using the tpm_tis-spi driver on a system missing the physical TPM,
a null pointer exception was observed.

    [    0.938677] Unable to handle kernel NULL pointer dereference at virtual address 00000004
    [    0.939020] pgd = 10c753cb
    [    0.939237] [00000004] *pgd=00000000
    [    0.939808] Internal error: Oops: 5 [#1] SMP ARM
    [    0.940157] CPU: 0 PID: 48 Comm: kworker/u4:1 Not tainted 5.15.10-dd1e40c #1
    [    0.940364] Hardware name: Generic DT based system
    [    0.940601] Workqueue: events_unbound async_run_entry_fn
    [    0.941048] PC is at tpm_tis_remove+0x28/0xb4
    [    0.941196] LR is at tpm_tis_core_init+0x170/0x6ac

This is due to an attempt in 'tpm_tis_remove' to use the drvdata, which
was not initialized in 'tpm_tis_core_init' prior to the first error.

Move the initialization of drvdata earlier so 'tpm_tis_remove' has
access to it.

Signed-off-by: Patrick Williams &lt;patrick@stwcx.xyz&gt;
Fixes: 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries")
Cc: stable@vger.kernel.org
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tpm: fix potential NULL pointer access in tpm_del_char_device</title>
<updated>2022-01-08T22:18:49+00:00</updated>
<author>
<name>Lino Sanfilippo</name>
<email>LinoSanfilippo@gmx.de</email>
</author>
<published>2021-12-20T15:06:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=eabad7ba2c752392ae50f24a795093fb115b686d'/>
<id>eabad7ba2c752392ae50f24a795093fb115b686d</id>
<content type='text'>
Some SPI controller drivers unregister the controller in the shutdown
handler (e.g. BCM2835). If such a controller is used with a TPM 2 slave
chip-&gt;ops may be accessed when it is already NULL:

At system shutdown the pre-shutdown handler tpm_class_shutdown() shuts down
TPM 2 and sets chip-&gt;ops to NULL. Then at SPI controller unregistration
tpm_tis_spi_remove() is called and eventually calls tpm_del_char_device()
which tries to shut down TPM 2 again. Thereby it accesses chip-&gt;ops again:
(tpm_del_char_device calls tpm_chip_start which calls tpm_clk_enable which
calls chip-&gt;ops-&gt;clk_enable).

Avoid the NULL pointer access by testing if chip-&gt;ops is valid and skipping
the TPM 2 shutdown procedure in case it is NULL.

Cc: stable@vger.kernel.org
Signed-off-by: Lino Sanfilippo &lt;LinoSanfilippo@gmx.de&gt;
Fixes: 39d0099f9439 ("powerpc/pseries: Add shutdown() to vio_driver and vio_bus")
Reviewed-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Tested-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some SPI controller drivers unregister the controller in the shutdown
handler (e.g. BCM2835). If such a controller is used with a TPM 2 slave
chip-&gt;ops may be accessed when it is already NULL:

At system shutdown the pre-shutdown handler tpm_class_shutdown() shuts down
TPM 2 and sets chip-&gt;ops to NULL. Then at SPI controller unregistration
tpm_tis_spi_remove() is called and eventually calls tpm_del_char_device()
which tries to shut down TPM 2 again. Thereby it accesses chip-&gt;ops again:
(tpm_del_char_device calls tpm_chip_start which calls tpm_clk_enable which
calls chip-&gt;ops-&gt;clk_enable).

Avoid the NULL pointer access by testing if chip-&gt;ops is valid and skipping
the TPM 2 shutdown procedure in case it is NULL.

Cc: stable@vger.kernel.org
Signed-off-by: Lino Sanfilippo &lt;LinoSanfilippo@gmx.de&gt;
Fixes: 39d0099f9439 ("powerpc/pseries: Add shutdown() to vio_driver and vio_bus")
Reviewed-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Tested-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tpm: Add Upgrade/Reduced mode support for TPM2 modules</title>
<updated>2022-01-08T22:18:47+00:00</updated>
<author>
<name>axelj</name>
<email>axelj@axis.com</email>
</author>
<published>2021-12-13T07:09:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0aa698787aa2a9e8840987e54ba2982559de6404'/>
<id>0aa698787aa2a9e8840987e54ba2982559de6404</id>
<content type='text'>
If something went wrong during the TPM firmware upgrade, like power
failure or the firmware image file get corrupted, the TPM might end
up in Upgrade or Failure mode upon the next start. The state is
persistent between the TPM power cycle/restart.

According to TPM specification:
 * If the TPM is in Upgrade mode, it will answer with TPM2_RC_UPGRADE
   to all commands except TPM2_FieldUpgradeData(). It may also accept
   other commands if it is able to complete them using the previously
   installed firmware.
 * If the TPM is in Failure mode, it will allow performing TPM
   initialization but will not provide any crypto operations.
   Will happily respond to Field Upgrade calls.

Change the behavior of the tpm2_auto_startup(), so it detects the active
running mode of the TPM by adding the following checks.  If
tpm2_do_selftest() call returns TPM2_RC_UPGRADE, the TPM is in Upgrade
mode.
If the TPM is in Failure mode, it will successfully respond to both
tpm2_do_selftest() and tpm2_startup() calls. Although, will fail to
answer to tpm2_get_cc_attrs_tbl(). Use this fact to conclude that TPM is
in Failure mode.

If detected that the TPM is in the Upgrade or Failure mode, the function
sets TPM_CHIP_FLAG_FIRMWARE_UPGRADE_MODE flag.

The TPM_CHIP_FLAG_FIRMWARE_UPGRADE_MODE flag is used later during driver
initialization/deinitialization to disable functionality which makes no
sense or will fail in the current TPM state. Following functionality is
affected:
 * Do not register TPM as a hwrng
 * Do not register sysfs entries which provide information impossible to
   obtain in limited mode
 * Do not register resource managed character device

Signed-off-by: axelj &lt;axelj@axis.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If something went wrong during the TPM firmware upgrade, like power
failure or the firmware image file get corrupted, the TPM might end
up in Upgrade or Failure mode upon the next start. The state is
persistent between the TPM power cycle/restart.

According to TPM specification:
 * If the TPM is in Upgrade mode, it will answer with TPM2_RC_UPGRADE
   to all commands except TPM2_FieldUpgradeData(). It may also accept
   other commands if it is able to complete them using the previously
   installed firmware.
 * If the TPM is in Failure mode, it will allow performing TPM
   initialization but will not provide any crypto operations.
   Will happily respond to Field Upgrade calls.

Change the behavior of the tpm2_auto_startup(), so it detects the active
running mode of the TPM by adding the following checks.  If
tpm2_do_selftest() call returns TPM2_RC_UPGRADE, the TPM is in Upgrade
mode.
If the TPM is in Failure mode, it will successfully respond to both
tpm2_do_selftest() and tpm2_startup() calls. Although, will fail to
answer to tpm2_get_cc_attrs_tbl(). Use this fact to conclude that TPM is
in Failure mode.

If detected that the TPM is in the Upgrade or Failure mode, the function
sets TPM_CHIP_FLAG_FIRMWARE_UPGRADE_MODE flag.

The TPM_CHIP_FLAG_FIRMWARE_UPGRADE_MODE flag is used later during driver
initialization/deinitialization to disable functionality which makes no
sense or will fail in the current TPM state. Following functionality is
affected:
 * Do not register TPM as a hwrng
 * Do not register sysfs entries which provide information impossible to
   obtain in limited mode
 * Do not register resource managed character device

Signed-off-by: axelj &lt;axelj@axis.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>char: tpm: cr50: Set TPM_FIRMWARE_POWER_MANAGED based on device property</title>
<updated>2022-01-08T22:18:45+00:00</updated>
<author>
<name>Rob Barnes</name>
<email>robbarnes@google.com</email>
</author>
<published>2021-12-06T12:03:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5887d7f4a8c4310a75ca45f576f26b3d21250881'/>
<id>5887d7f4a8c4310a75ca45f576f26b3d21250881</id>
<content type='text'>
Set TPM_FIRMWARE_POWER_MANAGED flag based on 'firmware-power-managed'
ACPI DSD property. For the CR50 TPM, this flag defaults to true when
the property is unset.

When this flag is set to false, the CR50 TPM driver will always send
a shutdown command whenever the system suspends.

Signed-off-by: Rob Barnes &lt;robbarnes@google.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Set TPM_FIRMWARE_POWER_MANAGED flag based on 'firmware-power-managed'
ACPI DSD property. For the CR50 TPM, this flag defaults to true when
the property is unset.

When this flag is set to false, the CR50 TPM driver will always send
a shutdown command whenever the system suspends.

Signed-off-by: Rob Barnes &lt;robbarnes@google.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tpm_tis: Fix an error handling path in 'tpm_tis_core_init()'</title>
<updated>2022-01-08T22:18:41+00:00</updated>
<author>
<name>Christophe Jaillet</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2021-11-06T16:42:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e96d52822f5ac0a25de78f95cd23421bcbc93584'/>
<id>e96d52822f5ac0a25de78f95cd23421bcbc93584</id>
<content type='text'>
Commit 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent
queries") has moved some code around without updating the error handling
path.

This is now pointless to 'goto out_err' when neither 'clk_enable()' nor
'ioremap()' have been called yet.

Make a direct return instead to avoid undoing things that have not been
done.

Fixes: 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries")
Signed-off-by: Christophe Jaillet &lt;christophe.jaillet@wanadoo.fr&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent
queries") has moved some code around without updating the error handling
path.

This is now pointless to 'goto out_err' when neither 'clk_enable()' nor
'ioremap()' have been called yet.

Make a direct return instead to avoid undoing things that have not been
done.

Fixes: 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries")
Signed-off-by: Christophe Jaillet &lt;christophe.jaillet@wanadoo.fr&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tpm: tpm_tis_spi_cr50: Add default RNG quality</title>
<updated>2022-01-08T22:18:38+00:00</updated>
<author>
<name>AngeloGioacchino Del Regno</name>
<email>angelogioacchino.delregno@collabora.com</email>
</author>
<published>2021-10-29T08:09:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d2704808f24fbc869ba54df82d4b1af49ab496e2'/>
<id>d2704808f24fbc869ba54df82d4b1af49ab496e2</id>
<content type='text'>
To allow this device to fill the kernel's entropy pool at boot,
setup a default quality for the hwrng found in Cr50.

After some testing with rngtest and dieharder it was, in short,
discovered that the RNG produces fair quality randomness, giving
around 99.93% successes in rngtest FIPS140-2.

Notably, though, when testing with dieharder it was noticed that
we get 3 WEAK results over 114, which isn't optimal, and also
the p-values distribution wasn't uniform in all the cases, so a
conservative quality value was chosen by applying an arbitrary
penalty to the calculated values.

For reference, this is how the values were calculated:

The dieharder results were averaged, then normalized (0-1000)
and re-averaged with the rngtest result (where the result was
given a score of 99.93% of 1000, so 999.3), then aggregated
together and averaged again.
An arbitrary penalty of -100 was applied due to the retrieved
value, which brings us finally to 700.

Signed-off-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@collabora.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
To allow this device to fill the kernel's entropy pool at boot,
setup a default quality for the hwrng found in Cr50.

After some testing with rngtest and dieharder it was, in short,
discovered that the RNG produces fair quality randomness, giving
around 99.93% successes in rngtest FIPS140-2.

Notably, though, when testing with dieharder it was noticed that
we get 3 WEAK results over 114, which isn't optimal, and also
the p-values distribution wasn't uniform in all the cases, so a
conservative quality value was chosen by applying an arbitrary
penalty to the calculated values.

For reference, this is how the values were calculated:

The dieharder results were averaged, then normalized (0-1000)
and re-averaged with the rngtest result (where the result was
given a score of 99.93% of 1000, so 999.3), then aggregated
together and averaged again.
An arbitrary penalty of -100 was applied due to the retrieved
value, which brings us finally to 700.

Signed-off-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@collabora.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tpm/st33zp24: drop unneeded over-commenting</title>
<updated>2022-01-08T22:18:37+00:00</updated>
<author>
<name>Sohaib Mohamed</name>
<email>sohaib.amhmd@gmail.com</email>
</author>
<published>2021-10-13T09:21:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=f04510f26f82aa7cd0bf932760f01b01a010869f'/>
<id>f04510f26f82aa7cd0bf932760f01b01a010869f</id>
<content type='text'>
Remove parameter descriptions from all static functions.
Remove the comment altogether that does not tell what the function does.

Suggested-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Sohaib Mohamed &lt;sohaib.amhmd@gmail.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove parameter descriptions from all static functions.
Remove the comment altogether that does not tell what the function does.

Suggested-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Sohaib Mohamed &lt;sohaib.amhmd@gmail.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tpm: add request_locality before write TPM_INT_ENABLE</title>
<updated>2022-01-08T22:18:34+00:00</updated>
<author>
<name>Chen Jun</name>
<email>chenjun102@huawei.com</email>
</author>
<published>2021-10-13T06:25:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0ef333f5ba7f24f5d8478425c163d3097f1c7afd'/>
<id>0ef333f5ba7f24f5d8478425c163d3097f1c7afd</id>
<content type='text'>
Locality is not appropriately requested before writing the int mask.
Add the missing boilerplate.

Fixes: e6aef069b6e9 ("tpm_tis: convert to using locality callbacks")
Signed-off-by: Chen Jun &lt;chenjun102@huawei.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Locality is not appropriately requested before writing the int mask.
Add the missing boilerplate.

Fixes: e6aef069b6e9 ("tpm_tis: convert to using locality callbacks")
Signed-off-by: Chen Jun &lt;chenjun102@huawei.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tpm_tis_spi: Add missing SPI ID</title>
<updated>2021-10-26T02:03:34+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2021-09-24T14:41:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7eba41fe8c7bb01ff3d4b757bd622375792bc720'/>
<id>7eba41fe8c7bb01ff3d4b757bd622375792bc720</id>
<content type='text'>
In commit c46ed2281bbe ("tpm_tis_spi: add missing SPI device ID entries")
we added SPI IDs for all the DT aliases to handle the fact that we always
use SPI modaliases to load modules even when probed via DT however the
mentioned commit missed that the SPI and OF device ID entries did not
match and were different and so DT nodes with compatible
"tcg,tpm_tis-spi" will not match.  Add an extra ID for tpm_tis-spi
rather than just fix the existing one since what's currently there is
going to be better for anyone actually using SPI IDs to instantiate.

Fixes: c46ed2281bbe ("tpm_tis_spi: add missing SPI device ID entries")
Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In commit c46ed2281bbe ("tpm_tis_spi: add missing SPI device ID entries")
we added SPI IDs for all the DT aliases to handle the fact that we always
use SPI modaliases to load modules even when probed via DT however the
mentioned commit missed that the SPI and OF device ID entries did not
match and were different and so DT nodes with compatible
"tcg,tpm_tis-spi" will not match.  Add an extra ID for tpm_tis-spi
rather than just fix the existing one since what's currently there is
going to be better for anyone actually using SPI IDs to instantiate.

Fixes: c46ed2281bbe ("tpm_tis_spi: add missing SPI device ID entries")
Fixes: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tpm: fix Atmel TPM crash caused by too frequent queries</title>
<updated>2021-10-26T02:03:34+00:00</updated>
<author>
<name>Hao Wu</name>
<email>hao.wu@rubrik.com</email>
</author>
<published>2021-09-08T09:26:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=79ca6f74dae067681a779fd573c2eb59649989bc'/>
<id>79ca6f74dae067681a779fd573c2eb59649989bc</id>
<content type='text'>
The Atmel TPM 1.2 chips crash with error
`tpm_try_transmit: send(): error -62` since kernel 4.14.
It is observed from the kernel log after running `tpm_sealdata -z`.
The error thrown from the command is as follows
```
$ tpm_sealdata -z
Tspi_Key_LoadKey failed: 0x00001087 - layer=tddl,
code=0087 (135), I/O error
```

The issue was reproduced with the following Atmel TPM chip:
```
$ tpm_version
T0  TPM 1.2 Version Info:
  Chip Version:        1.2.66.1
  Spec Level:          2
  Errata Revision:     3
  TPM Vendor ID:       ATML
  TPM Version:         01010000
  Manufacturer Info:   41544d4c
```

The root cause of the issue is due to the TPM calls to msleep()
were replaced with usleep_range() [1], which reduces
the actual timeout. Via experiments, it is observed that
the original msleep(5) actually sleeps for 15ms.
Because of a known timeout issue in Atmel TPM 1.2 chip,
the shorter timeout than 15ms can cause the error described above.

A few further changes in kernel 4.16 [2] and 4.18 [3, 4] further
reduced the timeout to less than 1ms. With experiments,
the problematic timeout in the latest kernel is the one
for `wait_for_tpm_stat`.

To fix it, the patch reverts the timeout of `wait_for_tpm_stat`
to 15ms for all Atmel TPM 1.2 chips, but leave it untouched
for Ateml TPM 2.0 chip, and chips from other vendors.
As explained above, the chosen 15ms timeout is
the actual timeout before this issue introduced,
thus the old value is used here.
Particularly, TPM_ATML_TIMEOUT_WAIT_STAT_MIN is set to 14700us,
TPM_ATML_TIMEOUT_WAIT_STAT_MIN is set to 15000us according to
the existing TPM_TIMEOUT_RANGE_US (300us).
The fixed has been tested in the system with the affected Atmel chip
with no issues observed after boot up.

References:
[1] 9f3fc7bcddcb tpm: replace msleep() with usleep_range() in TPM
1.2/2.0 generic drivers
[2] cf151a9a44d5 tpm: reduce tpm polling delay in tpm_tis_core
[3] 59f5a6b07f64 tpm: reduce poll sleep time in tpm_transmit()
[4] 424eaf910c32 tpm: reduce polling time to usecs for even finer
granularity

Fixes: 9f3fc7bcddcb ("tpm: replace msleep() with usleep_range() in TPM 1.2/2.0 generic drivers")
Link: https://patchwork.kernel.org/project/linux-integrity/patch/20200926223150.109645-1-hao.wu@rubrik.com/
Signed-off-by: Hao Wu &lt;hao.wu@rubrik.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The Atmel TPM 1.2 chips crash with error
`tpm_try_transmit: send(): error -62` since kernel 4.14.
It is observed from the kernel log after running `tpm_sealdata -z`.
The error thrown from the command is as follows
```
$ tpm_sealdata -z
Tspi_Key_LoadKey failed: 0x00001087 - layer=tddl,
code=0087 (135), I/O error
```

The issue was reproduced with the following Atmel TPM chip:
```
$ tpm_version
T0  TPM 1.2 Version Info:
  Chip Version:        1.2.66.1
  Spec Level:          2
  Errata Revision:     3
  TPM Vendor ID:       ATML
  TPM Version:         01010000
  Manufacturer Info:   41544d4c
```

The root cause of the issue is due to the TPM calls to msleep()
were replaced with usleep_range() [1], which reduces
the actual timeout. Via experiments, it is observed that
the original msleep(5) actually sleeps for 15ms.
Because of a known timeout issue in Atmel TPM 1.2 chip,
the shorter timeout than 15ms can cause the error described above.

A few further changes in kernel 4.16 [2] and 4.18 [3, 4] further
reduced the timeout to less than 1ms. With experiments,
the problematic timeout in the latest kernel is the one
for `wait_for_tpm_stat`.

To fix it, the patch reverts the timeout of `wait_for_tpm_stat`
to 15ms for all Atmel TPM 1.2 chips, but leave it untouched
for Ateml TPM 2.0 chip, and chips from other vendors.
As explained above, the chosen 15ms timeout is
the actual timeout before this issue introduced,
thus the old value is used here.
Particularly, TPM_ATML_TIMEOUT_WAIT_STAT_MIN is set to 14700us,
TPM_ATML_TIMEOUT_WAIT_STAT_MIN is set to 15000us according to
the existing TPM_TIMEOUT_RANGE_US (300us).
The fixed has been tested in the system with the affected Atmel chip
with no issues observed after boot up.

References:
[1] 9f3fc7bcddcb tpm: replace msleep() with usleep_range() in TPM
1.2/2.0 generic drivers
[2] cf151a9a44d5 tpm: reduce tpm polling delay in tpm_tis_core
[3] 59f5a6b07f64 tpm: reduce poll sleep time in tpm_transmit()
[4] 424eaf910c32 tpm: reduce polling time to usecs for even finer
granularity

Fixes: 9f3fc7bcddcb ("tpm: replace msleep() with usleep_range() in TPM 1.2/2.0 generic drivers")
Link: https://patchwork.kernel.org/project/linux-integrity/patch/20200926223150.109645-1-hao.wu@rubrik.com/
Signed-off-by: Hao Wu &lt;hao.wu@rubrik.com&gt;
Reviewed-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
Signed-off-by: Jarkko Sakkinen &lt;jarkko@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
