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: <212818188b192db3b852ec69fde174fd887eafac.camel@HansenPartnership.com>
Date: Tue, 21 Oct 2025 09:15:55 -0700
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Jan Kiszka <jan.kiszka@...mens.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 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
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.

> 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?

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.

Regards,

James