On Wed, Apr 29, 2026 at 02:33:20PM +0000, Niedermayr, BENEDIKT wrote:
On 10/27/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.
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...
Hi all,
we recently also stumbled over this issue which led me here to this thread and maybe adding our observations helps to clarify things here a bit (hopefully) or at least augments the information related to firmware TPM based implementation based on ms-tpm-20-ref.
Based on the optee_ftpm repo, as Jan already described, which currently references commit 98b60a44aba7 of [1] suffers this exact issue because of the NV_CLOCK_UPDATE_INTERVAL [2] which is set to "12" and issues a write for each command after ~4 seconds have passed.
This config has been changed to "22" (on current master branch [3]) which is the allowed maximum when following the TPM spec (chapter 36.3.2 in [4]) which leads to round about 70 minutes, but optee_ftpm didn't move ahead to this commit, yet. This config exists for being able to adapt the write cycles to the specific wear conditions of the hardware.
Moreover the ms-tpm-20-ref repo seems to not be maintained anymore and one should rather switch to [6].
So there are currently firmware TPM implementations out there that lead to these frequent writes.
Really this would need a product and official bug bulletin for it to even consider a workaround. Speculation does not count.
AFAIK since the tpm-20-ref implementation basically only supports a file on disk or RAM backing storage, the optee_ftpm repo [5] provides it's own _plat_NV* implementations that replace the default ones and finally call OP-TEE's TEE_* secure storage API, which then routes to whatever backend OP-TEE is configured with (REE-FS or RPMB) – In our case the RPMB.
Because there are currently implementations out there (e.g. start using optee_ftpm) it may make sense to add this information to the kernel config's help text at least?
Your first forum to report such issues is the TPM vendor.
We are currently trying to bump optee_ftpm to use the more recent v1.84, but since we're no TCG member the PRs on github could get a bit adventurous (PR's not upstream, yet). Until then this is a valid issue that exists...
[2] https://github.com/microsoft/ms-tpm-20-ref/blob/98b60a44aba79b15fcce1c0d1e46...
[3] https://github.com/microsoft/ms-tpm-20-ref/blob/98b60a44aba79b15fcce1c0d1e46...
[4] https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-1-Arc...
[5] https://github.com/OP-TEE/optee_ftpm
[6] https://github.com/TrustedComputingGroup/TPM
BR, Benedikt
BR, Jarkko