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