linux-kernel - Re: [PATCH] KEYS: trusted: Use get

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <64e3e4e0a92848fd3b02a213c754f096d2026463.camel@HansenPartnership.com>
Date: Mon, 15 Dec 2025 07:18:41 +0900
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Jarkko Sakkinen <jarkko@...nel.org>, linux-integrity@...r.kernel.org
Cc: David Howells <dhowells@...hat.com>, Paul Moore <paul@...l-moore.com>, 
 James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>,
 Mimi Zohar <zohar@...ux.ibm.com>,  "open list:KEYS/KEYRINGS"
 <keyrings@...r.kernel.org>, "open list:SECURITY SUBSYSTEM"
 <linux-security-module@...r.kernel.org>, open list
 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KEYS: trusted: Use get_random-fallback for TPM

On Sun, 2025-12-14 at 23:32 +0200, Jarkko Sakkinen wrote:
> 1. tpm2_get_random() is costly when TCG_TPM2_HMAC is enabled and thus
> its
>    use should be pooled rather than directly used. This both reduces
>    latency and improves its predictability.
> 
> 2. Linux is better off overall if every subsystem uses the same
> source for
>    the random bistream as the de-facto choice, unless *force majeure*
>    reasons point to some other direction.
> 
> In the case, of TPM there is no reason for trusted keys to invoke TPM
> directly.

That assertion isn't correct: you seem to have forgotten we had this
argument six or seven years ago, but even that was a reprise of an even
earlier one.  Lore doesn't go back far enough for the intermediate one
on the tpm list, but the original was cc'd to lkml:

https://lore.kernel.org/all/1378920168.26698.64.camel@localhost/

The decision then was to use the same random source as the key
protection.  Unfortunately most of the active participants have moved
on from IBM and I don't have their current email addresses, but the
bottom line is there were good reasons to do trusted keys this way that
your assertions above don't overcome.  I'm not saying we shouldn't
reconsider the situation, but we need a reasoned debate rather than
simply doing it by fiat.

Regards,

James