On 21.10.25 18:15, James Bottomley wrote: > On Tue, 2025-10-21 at 14:46 +0200, Jan Kiszka wrote: >> From: Jan Kiszka <[email protected]> >> >> 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
