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
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
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/0ebdda848e16d5ef78d1342c2f... [2] https://github.com/OP-TEE/optee_ftpm
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-Sup...
BR, Jarkko
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/ee21db0a941decd3cac67925ea33... (Page 942 in [1])
-> ... ->
https://github.com/microsoft/ms-tpm-20-ref/blob/main/TPMCmd/tpm/src/subsyste... (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-Sup...
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
op-tee@lists.trustedfirmware.org
-
James Bottomley -
Jan Kiszka -
Jarkko Sakkinen