[PATCH] hwrng: tpm: Do not enable by default

[PATCH] hwrng: tpm: Do not enable by default

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM may write
the current time epoch to its NV storage every 4 seconds if there are
commands sent to it. The 60 seconds periodic update of the entropy pool
that the hwrng kthread does triggers this, causing about 4 writes per
requests. Makes 2 millions per year for a 24/7 device, and that is a lot
for its backing NV storage.

It is therefore better to make the user intentionally enable this,
providing a chance to read the warning.

[1] https://github.com/Microsoft/ms-tpm-20-ref

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 drivers/char/tpm/Kconfig | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 8a8f692b6088..d64c929cacbe 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -45,13 +45,17 @@ config TCG_TPM2_HMAC
 config HW_RANDOM_TPM
 	bool "TPM HW Random Number Generator support"
 	depends on TCG_TPM && HW_RANDOM && !(TCG_TPM=y && HW_RANDOM=m)
-	default y
 	help
 	  This setting exposes the TPM's Random Number Generator as a hwrng
 	  device. This allows the kernel to collect randomness from the TPM at
 	  boot, and provides the TPM randomines in /dev/hwrng.
 
-	  If unsure, say Y.
+	  WARNING: Specifically firmware-based TPMs, possibly also hardware
+	  variants, can wear-out from the frequent requests issued by the
+	  Hardware Random Number Generator Core when filling the kernel's
+	  entropy pool. These requests are sent once every minute by default,
+	  and the TPM may write the current time to its NV storage for each of
+	  them.
 
 config TCG_TIS_CORE
 	tristate
-- 
2.51.0

Re: [PATCH] hwrng: tpm: Do not enable by default

[James Bottomley]

On Tue, 2025-10-21 at 14:46 +0200, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM may
> write the current time epoch to its NV storage every 4 seconds if
> there are commands sent to it. The 60 seconds periodic update of the
> entropy pool that the hwrng kthread does triggers this, causing about
> 4 writes per requests. Makes 2 millions per year for a 24/7 device,
> and that is a lot for its backing NV storage.

The Reference implementation does this because it's NV ram is main
memory and thus not subject to wear.  A physical TPM can defer these
writes and condition them to the lifespan expectancy of its NV store. 
If you've simply copied over the reference implementation backed by
wearable NV, then that might be the thing to fix.

> It is therefore better to make the user intentionally enable this,
> providing a chance to read the warning.

A standard TPM expects to be a secure RNG source, so is this merely
speculation or have you found a physical TPM that has failed due to NV
wear because of this?

Even if this were a problem, wouldn't a better solution be not to
gather entropy if the kernel pool is full enough?  We don't drain the
pool the whole time after all.

Regards,

James

Re: [PATCH] hwrng: tpm: Do not enable by default

[Jan Kiszka]

On 21.10.25 18:15, James Bottomley wrote:
> On Tue, 2025-10-21 at 14:46 +0200, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM may
>> write the current time epoch to its NV storage every 4 seconds if
>> there are commands sent to it. The 60 seconds periodic update of the
>> entropy pool that the hwrng kthread does triggers this, causing about
>> 4 writes per requests. Makes 2 millions per year for a 24/7 device,
>> and that is a lot for its backing NV storage.
> 
> The Reference implementation does this because it's NV ram is main
> memory and thus not subject to wear.  A physical TPM can defer these

"NV" strongly suggests that a real implementation should permanently
store whatever is written to it, no?

> writes and condition them to the lifespan expectancy of its NV store. 
> If you've simply copied over the reference implementation backed by
> wearable NV, then that might be the thing to fix.
> 

My impression is that this is exactly what at least half of the fTPM
world does, starting with [1] and now via [2]. I started a discussion
with security experts about how often a write back is actually needed
but have no answer yet.

>> It is therefore better to make the user intentionally enable this,
>> providing a chance to read the warning.
> 
> A standard TPM expects to be a secure RNG source, so is this merely
> speculation or have you found a physical TPM that has failed due to NV
> wear because of this?

I have not worn out any real TPM so far, only debugged the de-facto
standard fTPM in QEMU - and found this unexpected property.

At the same time, what should be different for a real TPM? It will not
have a battery-backed RTC either, thus will live from a clock source
which is reset after power-off. In order to avoid jumping back in its
own time, becoming vulnerable this way, I would expect a real TPM to
record the last seen time as well. Maybe it can do that smarter if it
can still write some bits after detecting power-loss, but that is also
speculation.

> 
> Even if this were a problem, wouldn't a better solution be not to
> gather entropy if the kernel pool is full enough?  We don't drain the
> pool the whole time after all.
> 

That is a valid question, but at least I'm not deep enough into all of
this to answer it.

Jan

[1]
https://github.com/microsoft/ms-tpm-20-ref/commit/0ebdda848e16d5ef78d1342c2fdfdd6dffb1004e
[2] https://github.com/OP-TEE/optee_ftpm

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH] hwrng: tpm: Do not enable by default

[Jarkko Sakkinen]

On Tue, Oct 21, 2025 at 02:46:15PM +0200, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM may write
> the current time epoch to its NV storage every 4 seconds if there are
> commands sent to it. The 60 seconds periodic update of the entropy pool
> that the hwrng kthread does triggers this, causing about 4 writes per
> requests. Makes 2 millions per year for a 24/7 device, and that is a lot
> for its backing NV storage.
> 
> It is therefore better to make the user intentionally enable this,
> providing a chance to read the warning.
> 
> [1] https://github.com/Microsoft/ms-tpm-20-ref
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Looking at DRBG_* from [1] I don't see anything you describe. If OPTEE
writes NVRAM,  then the implementation is broken.

Also AFAIK, it is pre-seeded per power cycle. There's nothing that even
distantly relates on using NVRAM.

[1] https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-4-Supporting-Routines-Code.pdf

BR, Jarkko

Re: [PATCH] hwrng: tpm: Do not enable by default

[Jan Kiszka]

On 27.10.25 20:51, Jarkko Sakkinen wrote:
> On Tue, Oct 21, 2025 at 02:46:15PM +0200, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM may write
>> the current time epoch to its NV storage every 4 seconds if there are
>> commands sent to it. The 60 seconds periodic update of the entropy pool
>> that the hwrng kthread does triggers this, causing about 4 writes per
>> requests. Makes 2 millions per year for a 24/7 device, and that is a lot
>> for its backing NV storage.
>>
>> It is therefore better to make the user intentionally enable this,
>> providing a chance to read the warning.
>>
>> [1] https://github.com/Microsoft/ms-tpm-20-ref
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> 
> Looking at DRBG_* from [1] I don't see anything you describe. If OPTEE
> writes NVRAM,  then the implementation is broken.

It's not OP-TEE, but it might be indeed an artifact of the reference
implementation that the fTPM is using because it is also targeting
simulation:

https://github.com/microsoft/ms-tpm-20-ref/blob/ee21db0a941decd3cac67925ea3310873af60ab3/TPMCmd/tpm/src/main/ExecCommand.c#L99
(Page 942 in [1])

-> ... ->

https://github.com/microsoft/ms-tpm-20-ref/blob/main/TPMCmd/tpm/src/subsystem/Time.c#L68
(Page 1075 in [1])

> 
> Also AFAIK, it is pre-seeded per power cycle. There's nothing that even
> distantly relates on using NVRAM.
> 
> [1] https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-4-Supporting-Routines-Code.pdf
> 
> BR, Jarkko

Given how detailed [1] is, we likely need to address that directly there
to avoid spreading this issue into fTPMs. Fact is, that there firmware
implementations out there which exactly do what [1] suggests: writing to
NV every 4 seconds on every command.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH] hwrng: tpm: Do not enable by default

[Jarkko Sakkinen]

On Tue, Oct 28, 2025 at 06:46:39AM +0100, Jan Kiszka wrote:
> On 27.10.25 20:51, Jarkko Sakkinen wrote:
> > On Tue, Oct 21, 2025 at 02:46:15PM +0200, Jan Kiszka wrote:
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>
> >> As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM may write
> >> the current time epoch to its NV storage every 4 seconds if there are
> >> commands sent to it. The 60 seconds periodic update of the entropy pool
> >> that the hwrng kthread does triggers this, causing about 4 writes per
> >> requests. Makes 2 millions per year for a 24/7 device, and that is a lot
> >> for its backing NV storage.
> >>
> >> It is therefore better to make the user intentionally enable this,
> >> providing a chance to read the warning.
> >>
> >> [1] https://github.com/Microsoft/ms-tpm-20-ref
> >>
> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> > 
> > Looking at DRBG_* from [1] I don't see anything you describe. If OPTEE
> > writes NVRAM,  then the implementation is broken.
> 
> It's not OP-TEE, but it might be indeed an artifact of the reference
> implementation that the fTPM is using because it is also targeting
> simulation:
> 
> https://github.com/microsoft/ms-tpm-20-ref/blob/ee21db0a941decd3cac67925ea3310873af60ab3/TPMCmd/tpm/src/main/ExecCommand.c#L99
> (Page 942 in [1])
> 
> -> ... ->
> 
> https://github.com/microsoft/ms-tpm-20-ref/blob/main/TPMCmd/tpm/src/subsystem/Time.c#L68
> (Page 1075 in [1])
> 
> > 
> > Also AFAIK, it is pre-seeded per power cycle. There's nothing that even
> > distantly relates on using NVRAM.
> > 
> > [1] https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-4-Supporting-Routines-Code.pdf
> > 
> > BR, Jarkko
> 
> Given how detailed [1] is, we likely need to address that directly there
> to avoid spreading this issue into fTPMs. Fact is, that there firmware
> implementations out there which exactly do what [1] suggests: writing to
> NV every 4 seconds on every command.

We don't reference code as a certified hardware product, sorry.

> 
> Jan
> 
> -- 
> Siemens AG, Foundational Technologies
> Linux Expert Center

BR, Jarkko

Re: [PATCH] hwrng: tpm: Do not enable by default

[Jan Kiszka]

On 09.11.25 05:43, Jarkko Sakkinen wrote:
> On Tue, Oct 28, 2025 at 06:46:39AM +0100, Jan Kiszka wrote:
>> On 27.10.25 20:51, Jarkko Sakkinen wrote:
>>> On Tue, Oct 21, 2025 at 02:46:15PM +0200, Jan Kiszka wrote:
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>> As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM may write
>>>> the current time epoch to its NV storage every 4 seconds if there are
>>>> commands sent to it. The 60 seconds periodic update of the entropy pool
>>>> that the hwrng kthread does triggers this, causing about 4 writes per
>>>> requests. Makes 2 millions per year for a 24/7 device, and that is a lot
>>>> for its backing NV storage.
>>>>
>>>> It is therefore better to make the user intentionally enable this,
>>>> providing a chance to read the warning.
>>>>
>>>> [1] https://github.com/Microsoft/ms-tpm-20-ref
>>>>
>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>
>>> Looking at DRBG_* from [1] I don't see anything you describe. If OPTEE
>>> writes NVRAM,  then the implementation is broken.
>>
>> It's not OP-TEE, but it might be indeed an artifact of the reference
>> implementation that the fTPM is using because it is also targeting
>> simulation:
>>
>> https://github.com/microsoft/ms-tpm-20-ref/blob/ee21db0a941decd3cac67925ea3310873af60ab3/TPMCmd/tpm/src/main/ExecCommand.c#L99
>> (Page 942 in [1])
>>
>> -> ... ->
>>
>> https://github.com/microsoft/ms-tpm-20-ref/blob/main/TPMCmd/tpm/src/subsystem/Time.c#L68
>> (Page 1075 in [1])
>>
>>>
>>> Also AFAIK, it is pre-seeded per power cycle. There's nothing that even
>>> distantly relates on using NVRAM.
>>>
>>> [1] https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-4-Supporting-Routines-Code.pdf
>>>
>>> BR, Jarkko
>>
>> Given how detailed [1] is, we likely need to address that directly there
>> to avoid spreading this issue into fTPMs. Fact is, that there firmware
>> implementations out there which exactly do what [1] suggests: writing to
>> NV every 4 seconds on every command.
> 
> We don't reference code as a certified hardware product, sorry.
> 

Means what?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH] hwrng: tpm: Do not enable by default

[Niedermayr, BENEDIKT]

On 10/27/25 20:51, Jarkko Sakkinen wrote:
> On Tue, Oct 21, 2025 at 02:46:15PM +0200, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM may write
>> the current time epoch to its NV storage every 4 seconds if there are
>> commands sent to it. The 60 seconds periodic update of the entropy pool
>> that the hwrng kthread does triggers this, causing about 4 writes per
>> requests. Makes 2 millions per year for a 24/7 device, and that is a lot
>> for its backing NV storage.
>>
>> It is therefore better to make the user intentionally enable this,
>> providing a chance to read the warning.
>>
>> [1] https://github.com/Microsoft/ms-tpm-20-ref
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> 
> Looking at DRBG_* from [1] I don't see anything you describe. If OPTEE
> writes NVRAM,  then the implementation is broken.
> 
> Also AFAIK, it is pre-seeded per power cycle. There's nothing that even
> distantly relates on using NVRAM.
> 
> [1] https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-4-Supporting-Routines-Code.pdf

Hi all,

we recently also stumbled over this issue which led me here to this 
thread and maybe adding our observations helps to clarify things here a 
bit (hopefully) or at least augments the information related to firmware 
TPM based implementation based on ms-tpm-20-ref.

Based on the optee_ftpm repo, as Jan already described, which currently 
references commit 98b60a44aba7 of [1] suffers this exact issue because 
of the NV_CLOCK_UPDATE_INTERVAL [2] which is set to "12" and issues a 
write for each command after ~4 seconds have passed.

This config has been changed to "22" (on current master branch [3]) 
which is the allowed maximum when following the TPM spec (chapter 36.3.2 
in [4]) which leads to round about 70 minutes, but optee_ftpm didn't 
move ahead to this commit, yet.
This config exists for being able to adapt the write cycles to the 
specific wear conditions of the hardware.

Moreover the ms-tpm-20-ref repo seems to not be maintained anymore and 
one should rather switch to [6].

So there are currently firmware TPM implementations out there that lead 
to these frequent writes.

AFAIK since the tpm-20-ref implementation basically only supports a file 
on disk or RAM backing storage, the optee_ftpm repo [5] provides it's 
own _plat_NV* implementations that replace the default ones and finally 
call OP-TEE's TEE_* secure storage API, which then routes to whatever 
backend OP-TEE is configured with (REE-FS or RPMB) – In our case the RPMB.

Because there are currently implementations out there (e.g. start using 
optee_ftpm) it may make sense to add this information to the kernel 
config's help text at least?

We are currently trying to bump optee_ftpm to use the more recent v1.84, 
but since we're no TCG member the PRs on github could get a bit 
adventurous (PR's not upstream, yet).
Until then this is a valid issue that exists...


[2] 
https://github.com/microsoft/ms-tpm-20-ref/blob/98b60a44aba79b15fcce1c0d1e46cf5918400f6a/TPMCmd/tpm/include/TpmProfile.h#L199 


[3] 
https://github.com/microsoft/ms-tpm-20-ref/blob/98b60a44aba79b15fcce1c0d1e46cf5918400f6a/TPMCmd/tpm/include/TpmProfile.h#L200

[4] 
https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-1-Architecture.pdf

[5] https://github.com/OP-TEE/optee_ftpm

[6] https://github.com/TrustedComputingGroup/TPM

BR,
Benedikt

Re: [PATCH] hwrng: tpm: Do not enable by default

[Jarkko Sakkinen]

On Wed, Apr 29, 2026 at 02:33:20PM +0000, Niedermayr, BENEDIKT wrote:
> On 10/27/25 20:51, Jarkko Sakkinen wrote:
> > On Tue, Oct 21, 2025 at 02:46:15PM +0200, Jan Kiszka wrote:
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>
> >> As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM may write
> >> the current time epoch to its NV storage every 4 seconds if there are
> >> commands sent to it. The 60 seconds periodic update of the entropy pool
> >> that the hwrng kthread does triggers this, causing about 4 writes per
> >> requests. Makes 2 millions per year for a 24/7 device, and that is a lot
> >> for its backing NV storage.
> >>
> >> It is therefore better to make the user intentionally enable this,
> >> providing a chance to read the warning.
> >>
> >> [1] https://github.com/Microsoft/ms-tpm-20-ref
> >>
> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> > 
> > Looking at DRBG_* from [1] I don't see anything you describe. If OPTEE
> > writes NVRAM,  then the implementation is broken.
> > 
> > Also AFAIK, it is pre-seeded per power cycle. There's nothing that even
> > distantly relates on using NVRAM.
> > 
> > [1] https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-4-Supporting-Routines-Code.pdf
> 
> Hi all,
> 
> we recently also stumbled over this issue which led me here to this 
> thread and maybe adding our observations helps to clarify things here a 
> bit (hopefully) or at least augments the information related to firmware 
> TPM based implementation based on ms-tpm-20-ref.
> 
> Based on the optee_ftpm repo, as Jan already described, which currently 
> references commit 98b60a44aba7 of [1] suffers this exact issue because 
> of the NV_CLOCK_UPDATE_INTERVAL [2] which is set to "12" and issues a 
> write for each command after ~4 seconds have passed.
> 
> This config has been changed to "22" (on current master branch [3]) 
> which is the allowed maximum when following the TPM spec (chapter 36.3.2 
> in [4]) which leads to round about 70 minutes, but optee_ftpm didn't 
> move ahead to this commit, yet.
> This config exists for being able to adapt the write cycles to the 
> specific wear conditions of the hardware.
> 
> Moreover the ms-tpm-20-ref repo seems to not be maintained anymore and 
> one should rather switch to [6].
> 
> So there are currently firmware TPM implementations out there that lead 
> to these frequent writes.

Really this would need a product and official bug bulletin for it to
even consider a workaround. Speculation does not count.

> 
> AFAIK since the tpm-20-ref implementation basically only supports a file 
> on disk or RAM backing storage, the optee_ftpm repo [5] provides it's 
> own _plat_NV* implementations that replace the default ones and finally 
> call OP-TEE's TEE_* secure storage API, which then routes to whatever 
> backend OP-TEE is configured with (REE-FS or RPMB) – In our case the RPMB.
> 
> Because there are currently implementations out there (e.g. start using 
> optee_ftpm) it may make sense to add this information to the kernel 
> config's help text at least?

Your first forum to report such issues is the TPM vendor.

> 
> We are currently trying to bump optee_ftpm to use the more recent v1.84, 
> but since we're no TCG member the PRs on github could get a bit 
> adventurous (PR's not upstream, yet).
> Until then this is a valid issue that exists...
> 
> 
> [2] 
> https://github.com/microsoft/ms-tpm-20-ref/blob/98b60a44aba79b15fcce1c0d1e46cf5918400f6a/TPMCmd/tpm/include/TpmProfile.h#L199 
> 
> 
> [3] 
> https://github.com/microsoft/ms-tpm-20-ref/blob/98b60a44aba79b15fcce1c0d1e46cf5918400f6a/TPMCmd/tpm/include/TpmProfile.h#L200
> 
> [4] 
> https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-1-Architecture.pdf
> 
> [5] https://github.com/OP-TEE/optee_ftpm
> 
> [6] https://github.com/TrustedComputingGroup/TPM
> 
> BR,
> Benedikt
> 

BR, Jarkko

Re: [PATCH] hwrng: tpm: Do not enable by default

[Jan Kiszka]

On 09.05.26 17:18, Jarkko Sakkinen wrote:
> On Wed, Apr 29, 2026 at 02:33:20PM +0000, Niedermayr, BENEDIKT wrote:
>> On 10/27/25 20:51, Jarkko Sakkinen wrote:
>>> On Tue, Oct 21, 2025 at 02:46:15PM +0200, Jan Kiszka wrote:
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>> As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM may write
>>>> the current time epoch to its NV storage every 4 seconds if there are
>>>> commands sent to it. The 60 seconds periodic update of the entropy pool
>>>> that the hwrng kthread does triggers this, causing about 4 writes per
>>>> requests. Makes 2 millions per year for a 24/7 device, and that is a lot
>>>> for its backing NV storage.
>>>>
>>>> It is therefore better to make the user intentionally enable this,
>>>> providing a chance to read the warning.
>>>>
>>>> [1] https://github.com/Microsoft/ms-tpm-20-ref
>>>>
>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>
>>> Looking at DRBG_* from [1] I don't see anything you describe. If OPTEE
>>> writes NVRAM,  then the implementation is broken.
>>>
>>> Also AFAIK, it is pre-seeded per power cycle. There's nothing that even
>>> distantly relates on using NVRAM.
>>>
>>> [1] https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-4-Supporting-Routines-Code.pdf
>>
>> Hi all,
>>
>> we recently also stumbled over this issue which led me here to this 
>> thread and maybe adding our observations helps to clarify things here a 
>> bit (hopefully) or at least augments the information related to firmware 
>> TPM based implementation based on ms-tpm-20-ref.
>>
>> Based on the optee_ftpm repo, as Jan already described, which currently 
>> references commit 98b60a44aba7 of [1] suffers this exact issue because 
>> of the NV_CLOCK_UPDATE_INTERVAL [2] which is set to "12" and issues a 
>> write for each command after ~4 seconds have passed.
>>
>> This config has been changed to "22" (on current master branch [3]) 
>> which is the allowed maximum when following the TPM spec (chapter 36.3.2 
>> in [4]) which leads to round about 70 minutes, but optee_ftpm didn't 
>> move ahead to this commit, yet.
>> This config exists for being able to adapt the write cycles to the 
>> specific wear conditions of the hardware.
>>
>> Moreover the ms-tpm-20-ref repo seems to not be maintained anymore and 
>> one should rather switch to [6].
>>
>> So there are currently firmware TPM implementations out there that lead 
>> to these frequent writes.
> 
> Really this would need a product and official bug bulletin for it to
> even consider a workaround. Speculation does not count.
> 

The key point Benedikt tries to make here is that the TPM 2 spec forces
any vendor to do something about persisting the last seen time at least
every 70 min. If they didn't do that, then they would violate the space
- arguably a bug. But, correct, it does not tell us anything about how
this happens in a random firmware TPM implementation.

>>
>> AFAIK since the tpm-20-ref implementation basically only supports a file 
>> on disk or RAM backing storage, the optee_ftpm repo [5] provides it's 
>> own _plat_NV* implementations that replace the default ones and finally 
>> call OP-TEE's TEE_* secure storage API, which then routes to whatever 
>> backend OP-TEE is configured with (REE-FS or RPMB) – In our case the RPMB.
>>
>> Because there are currently implementations out there (e.g. start using 
>> optee_ftpm) it may make sense to add this information to the kernel 
>> config's help text at least?
> 
> Your first forum to report such issues is the TPM vendor.

I would still not recommend anyone relying on a firmware TPM to turn on
CONFIG_HW_RANDOM_TPM if there are viable alternatives. In case of the
open source stack with optee_os + optee_ftpm, we know that at least one
exists: CONFIG_HW_RANDOM_OPTEE.

So, if there is no good place to document this in the kernel, maybe it
is worth to document it in optee_ftpm instead.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [PATCH] hwrng: tpm: Do not enable by default

[James Bottomley]

On Sun, 2026-05-10 at 22:42 +0200, Jan Kiszka wrote:
> On 09.05.26 17:18, Jarkko Sakkinen wrote:
> > On Wed, Apr 29, 2026 at 02:33:20PM +0000, Niedermayr, BENEDIKT
> > wrote:
> > > On 10/27/25 20:51, Jarkko Sakkinen wrote:
> > > > On Tue, Oct 21, 2025 at 02:46:15PM +0200, Jan Kiszka wrote:
> > > > > From: Jan Kiszka <jan.kiszka@siemens.com>
> > > > > 
> > > > > As seen with optee_ftpm, which uses ms-tpm-20-ref [1], a TPM
> > > > > may write the current time epoch to its NV storage every 4
> > > > > seconds if there are commands sent to it. The 60 seconds
> > > > > periodic update of the entropy pool that the hwrng kthread
> > > > > does triggers this, causing about 4 writes per requests.
> > > > > Makes 2 millions per year for a 24/7 device, and that is a
> > > > > lot for its backing NV storage.
> > > > > 
> > > > > It is therefore better to make the user intentionally enable
> > > > > this, providing a chance to read the warning.
> > > > > 
> > > > > [1] https://github.com/Microsoft/ms-tpm-20-ref
> > > > > 
> > > > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> > > > 
> > > > Looking at DRBG_* from [1] I don't see anything you describe.
> > > > If OPTEE writes NVRAM,  then the implementation is broken.
> > > > 
> > > > Also AFAIK, it is pre-seeded per power cycle. There's nothing
> > > > that even distantly relates on using NVRAM.
> > > > 
> > > > [1]
> > > > https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-4-Supporting-Routines-Code.pdf
> > > 
> > > Hi all,
> > > 
> > > we recently also stumbled over this issue which led me here to
> > > this thread and maybe adding our observations helps to clarify
> > > things here a bit (hopefully) or at least augments the
> > > information related to firmware TPM based implementation based on
> > > ms-tpm-20-ref.
> > > 
> > > Based on the optee_ftpm repo, as Jan already described, which
> > > currently references commit 98b60a44aba7 of [1] suffers this
> > > exact issue because of the NV_CLOCK_UPDATE_INTERVAL [2] which is
> > > set to "12" and issues a write for each command after ~4 seconds
> > > have passed.

You keep quoting this to us, and other parts of the spec.  However, you
forgot to quote from the Section 7 compliance statement in the same
spec which says:

   the NV subsystem of the reference implementation is not
   representative of the actual implementation of most physical NV
   implementations but is a crude analog.

I get that the the optee people failed to realize this and only just
corrected the mistake, but the fact is that all other TPM
implementations, both physical and firmware don't have this wear
problem you've given yourselves because they noticed.

> > > This config has been changed to "22" (on current master branch
> > > [3]) which is the allowed maximum when following the TPM spec
> > > (chapter 36.3.2 in [4]) which leads to round about 70 minutes,
> > > but optee_ftpm didn't move ahead to this commit, yet.
> > > This config exists for being able to adapt the write cycles to
> > > the specific wear conditions of the hardware.
> > > 
> > > Moreover the ms-tpm-20-ref repo seems to not be maintained
> > > anymore and one should rather switch to [6].
> > > 
> > > So there are currently firmware TPM implementations out there
> > > that lead to these frequent writes.

Yours is the only one I've ever come across.

> > Really this would need a product and official bug bulletin for it
> > to even consider a workaround. Speculation does not count.
> > 
> 
> The key point Benedikt tries to make here is that the TPM 2 spec
> forces any vendor to do something about persisting the last seen time
> at  least every 70 min. If they didn't do that, then they would
> violate the space 

That's correct, but a red herring: if the optee TPM had done this 70
minute flush ab initio you wouldn't have the wear problem because the
seed writes would be much less frequent.

> - arguably a bug.

Well, not following the spec is a bug, yes, but it's not a bug in the
kernel ...

Regards,

James