On 09.05.26 17:18, Jarkko Sakkinen wrote: > 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 <[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. >>>> >>>> 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 <[email protected]> >>> >>> 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-Supporting-Routines-Code.pdf >> >> 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. >
The key point Benedikt tries to make here is that the TPM 2 spec forces any vendor to do something about persisting the last seen time at least every 70 min. If they didn't do that, then they would violate the space - arguably a bug. But, correct, it does not tell us anything about how this happens in a random firmware TPM implementation. >> >> 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. I would still not recommend anyone relying on a firmware TPM to turn on CONFIG_HW_RANDOM_TPM if there are viable alternatives. In case of the open source stack with optee_os + optee_ftpm, we know that at least one exists: CONFIG_HW_RANDOM_OPTEE. So, if there is no good place to document this in the kernel, maybe it is worth to document it in optee_ftpm instead. Jan -- Siemens AG, Foundational Technologies Linux Expert Center
