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