linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: linux-integrity@vger.kernel.org
Cc: Jarkko Sakkinen <jarkko@kernel.org>,
	Eric Biggers <ebiggers@kernel.org>,
	David Howells <dhowells@redhat.com>,
	Paul Moore <paul@paul-moore.com>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Mimi Zohar <zohar@linux.ibm.com>,
	keyrings@vger.kernel.org (open list:KEYS/KEYRINGS),
	linux-security-module@vger.kernel.org (open list:SECURITY
	SUBSYSTEM), linux-kernel@vger.kernel.org (open list)
Subject: [PATCH v8 01/12] KEYS: trusted: Use get_random-fallback for TPM
Date: Tue, 16 Dec 2025 11:21:35 +0200	[thread overview]
Message-ID: <20251216092147.2326606-2-jarkko@kernel.org> (raw)
In-Reply-To: <20251216092147.2326606-1-jarkko@kernel.org>

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
   generating the random numbers required.

Thus, unset '.get_random', which causes fallback to kernel_get_random().

One might argue that TPM RNG should be used for the generated trusted keys,
so that they have matching entropy with the TPM internally generated
objects.

This argument does have some weight into it but as far cryptography goes,
FIPS certification sets the exact bar, not which exact FIPS certified RNG
will be used. Thus, the rational choice is obviously to pick the lowest
latency path, which is kernel RNG.

Finally, there is an actual defence in depth benefit when using kernel RNG
as it helps to mitigate TPM firmware bugs concerning RNG implementation,
given the obfuscation by the other entropy sources.

Reviewed-by: Eric Biggers <ebiggers@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
---
v7:
- A new patch. Simplifies follow up patches.
---
 security/keys/trusted-keys/trusted_tpm1.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
index 636acb66a4f6..7ce7e31bcdfb 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -6,6 +6,16 @@
  * See Documentation/security/keys/trusted-encrypted.rst
  */
 
+/**
+ * DOC: Random Number Generation
+ *
+ * tpm_get_random() was previously used here as the RNG in order to have equal
+ * entropy with the objects fully inside the TPM. However, as far as goes,
+ * kernel RNG is equally fine, as long as long as it is FIPS certified. Also,
+ * using kernel RNG has the benefit of mitigating bugs in the TPM firmware
+ * associated with the RNG.
+ */
+
 #include <crypto/hash_info.h>
 #include <crypto/sha1.h>
 #include <crypto/utils.h>
@@ -936,11 +946,6 @@ static int trusted_tpm_unseal(struct trusted_key_payload *p, char *datablob)
 	return ret;
 }
 
-static int trusted_tpm_get_random(unsigned char *key, size_t key_len)
-{
-	return tpm_get_random(chip, key, key_len);
-}
-
 static int __init init_digests(void)
 {
 	int i;
@@ -992,6 +997,5 @@ struct trusted_key_ops trusted_key_tpm_ops = {
 	.init = trusted_tpm_init,
 	.seal = trusted_tpm_seal,
 	.unseal = trusted_tpm_unseal,
-	.get_random = trusted_tpm_get_random,
 	.exit = trusted_tpm_exit,
 };
-- 
2.39.5


  reply	other threads:[~2025-12-16  9:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-16  9:21 [PATCH v8 00/12] Streamline TPM2 HMAC sessions Jarkko Sakkinen
2025-12-16  9:21 ` Jarkko Sakkinen [this message]
2025-12-16  9:21 ` [PATCH v8 02/12] KEYS: trusted: Use get_random_bytes_wait() instead of tpm_get_random() Jarkko Sakkinen
2025-12-19  9:21   ` Jonathan McDowell
2025-12-16  9:21 ` [PATCH v8 03/12] tpm: Orchestrate TPM commands in tpm_get_random() Jarkko Sakkinen
2025-12-19  9:43   ` Jonathan McDowell
2025-12-16  9:21 ` [PATCH v8 04/12] tpm: Change tpm_get_random() opportunistic Jarkko Sakkinen
2025-12-16 22:03   ` Jarkko Sakkinen
2025-12-19  9:42   ` Jonathan McDowell
2025-12-16  9:21 ` [PATCH v8 05/12] tpm2-sessions: Define TPM2_NAME_MAX_SIZE Jarkko Sakkinen
2025-12-19  9:32   ` Jonathan McDowell
2025-12-16  9:21 ` [PATCH v8 06/12] KEYS: trusted: Open code tpm2_buf_append() Jarkko Sakkinen
2025-12-16  9:21 ` [PATCH v8 07/12] KEYS: trusted: Remove dead branch from tpm2_unseal_cmd Jarkko Sakkinen
2025-12-19  9:37   ` Jonathan McDowell
2025-12-19 20:54   ` James Bottomley
2025-12-16  9:21 ` [PATCH v8 08/12] KEYS: trusted: Re-orchestrate tpm2_read_public() calls Jarkko Sakkinen
2025-12-16  9:21 ` [PATCH v8 09/12] tpm2-sessions: Remove the support for more than one authorization Jarkko Sakkinen
2025-12-16  9:21 ` [PATCH v8 10/12] tpm-buf: Remove tpm_buf_append_handle Jarkko Sakkinen
2025-12-16  9:21 ` [PATCH v8 11/12] tpm-buf: Merge TPM_BUF_BOUNDARY_ERROR and TPM_BUF_OVERFLOW Jarkko Sakkinen
2025-12-16  9:21 ` [PATCH v8 12/12] tpm-buf: Implement managed allocations Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251216092147.2326606-2-jarkko@kernel.org \
    --to=jarkko@kernel.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dhowells@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=jmorris@namei.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).