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

Jan Kiszka
2025-10-22T05:05:21Z

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