linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: linux-kernel@vger.kernel.org, tytso@mit.edu,
	linux-crypto@vger.kernel.org
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
Subject: [PATCH] random: avoid superfluous call to RDRAND in CRNG extraction
Date: Thu, 30 Dec 2021 17:50:52 +0100	[thread overview]
Message-ID: <20211230165052.2698-1-Jason@zx2c4.com> (raw)

RDRAND is not fast. RDRAND is actually quite slow. We've known this for
a while, which is why functions like get_random_u{32,64} were converted
to use batching of our ChaCha-based CRNG instead.

Yet CRNG extraction still includes a call to RDRAND, in the hot path of
every call to get_random_bytes(), /dev/urandom, and getrandom(2).

This call to RDRAND here seems quite superfluous. CRNG is already
extracting things based on a 256-bit key, based on good entropy, which
is then reseeded periodically, updated, backtrack-mutated, and so
forth. The CRNG extraction construction is something that we're already
relying on to be secure and solid. If it's not, that's a serious
problem, and it's unlikely that mixing in a measly 32 bits from RDRAND
is going to alleviate things.

There is one place, though, where such last-ditch moves might be
quasi-sensible, and that's before the CRNG is actually ready. In that case,
we're already very much operating from a position of trying to get
whatever we can, so we might as well throw in the RDRAND call because
why not.

But once the CRNG is actually up, it's simply not sensible. Removing the
call there improves performance on an i7-11850H by 370%. In other words,
the vast majority of the work done by extract_crng() prior to this commit
was devoted to fetching 32 bits of RDRAND.

This commit fixes the issue by only making that call to RDRAND when the
CRNG is not yet ready.

Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
 drivers/char/random.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 54086e9da05b..239b1455b1a8 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1030,7 +1030,7 @@ static void _extract_crng(struct crng_state *crng,
 				    &input_pool : NULL);
 	}
 	spin_lock_irqsave(&crng->lock, flags);
-	if (arch_get_random_long(&v))
+	if (unlikely(!crng_ready()) && arch_get_random_long(&v))
 		crng->state[14] ^= v;
 	chacha20_block(&crng->state[0], out);
 	if (crng->state[12] == 0)
-- 
2.34.1


             reply	other threads:[~2021-12-30 16:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-30 16:50 Jason A. Donenfeld [this message]
2021-12-30 22:13 ` Theodore Ts'o
2021-12-30 22:58   ` Jason A. Donenfeld
2021-12-31  3:35     ` Theodore Ts'o
2021-12-31 11:49       ` [PATCH v2] " Jason A. Donenfeld
2021-12-31 17:13         ` Theodore Ts'o
2022-01-04  5:03           ` Sandy Harris
2022-01-04  5:55             ` Theodore Ts'o
2022-01-20 15:03               ` Jason A. Donenfeld
2022-01-20 15:07                 ` [PATCH] random: use named fields for adjusting chacha state Jason A. Donenfeld
2022-01-20 17:50                   ` Theodore Ts'o
2022-01-20 21:53                     ` Jason A. Donenfeld
2022-01-05 15:28         ` [PATCH v2] random: avoid superfluous call to RDRAND in CRNG extraction Ard Biesheuvel

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=20211230165052.2698-1-Jason@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --subject='Re: [PATCH] random: avoid superfluous call to RDRAND in CRNG extraction' \
    /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

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).