linux-kernel - Re: [PATCH] hwrng: tpm: Do not enable by default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5539d518-5216-4730-a2ab-3c59d98d0229@siemens.com>
Date: Wed, 22 Oct 2025 07:05:17 +0200
From: Jan Kiszka <jan.kiszka@...mens.com>
To: James Bottomley <James.Bottomley@...senPartnership.com>,
 Peter Huewe <peterhuewe@....de>, Jarkko Sakkinen <jarkko@...nel.org>,
 linux-integrity@...r.kernel.org
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 Ilias Apalodimas <ilias.apalodimas@...aro.org>,
 Jens Wiklander <jens.wiklander@...aro.org>,
 OP-TEE TrustedFirmware <op-tee@...ts.trustedfirmware.org>,
 linux-crypto@...r.kernel.org
Subject: Re: [PATCH] hwrng: tpm: Do not enable by default

On 21.10.25 18:15, James Bottomley wrote:
> On Tue, 2025-10-21 at 14:46 +0200, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@...mens.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

"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