From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
ebiggers@kernel.org
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
Theodore Ts'o <tytso@mit.edu>,
Dominik Brodowski <linux@dominikbrodowski.net>,
Eric Biggers <ebiggers@google.com>
Subject: [PATCH v2] random: reseed more often immediately after booting
Date: Thu, 10 Mar 2022 14:10:50 -0700 [thread overview]
Message-ID: <20220310211050.135078-1-Jason@zx2c4.com> (raw)
In-Reply-To: <CAHmME9ohyKKX4Qg_dyGq36MxFkhBoVQYYgs8uUoCfBkJNqfX7Q@mail.gmail.com>
In order to chip away at the "premature first" problem, we augment our
existing entropy accounting with more frequent reseedings at boot.
The idea is that at boot, we're getting entropy from various places, and
we're not very sure which of early boot entropy is good and which isn't.
Even when we're crediting the entropy, we're still not totally certain
that it's any good. Since boot is the one time (aside from a compromise)
that we have zero entropy, it's important that we shephard entropy into
the crng fairly often.
At the same time, we don't want a "premature next" problem, whereby an
attacker can brute force individual bits of added entropy. In lieu of
going full-on Fortuna (for now), we can pick a simpler strategy of just
reseeding more often during the first 5 minutes after boot. This is
still bounded by the 256-bit entropy credit requirement, so we'll skip a
reseeding if we haven't reached that, but in case entropy /is/ coming
in, this ensures that it makes its way into the crng rather rapidly
during these early stages.
For this we start at 5 seconds after boot, and double that interval
until it's more than 5 minutes. After that, we then move to our normal
schedule of reseeding not more than once per 5 minutes.
One interesting caveat is that reseeding is presently on-demand, so
we're not reseeding at precisely the 5, 10, 20, 40, 80, 160 marks, but
rather whenever the crng is actually used and we've matched or exceeded
one of those marks. This means that we might wind up trying to reseed at
both second 79 and second 80, or at second 41 and second 80, or anywhere
in between. In that sense, this isn't quite imposing a minimum frequency
on reseeds during early boot, but simply bounding a maximum frequency.
Since we're still requiring 256 bits of entropy credits, this shouldn't
be a super large issue in terms of "premature next", and in the event
that we reseed a bit late and then miss the next reseeding due to not
enough entropy credits, we still have acquired more entropy by virtue of
having reseeded later.
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Eric Biggers <ebiggers@google.com>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
Changes v1->v2:
- Note "on-demand" funkiness in commit message.
- Always use READ_ONCE() with next_init_secs.
drivers/char/random.c | 28 +++++++++++++++++++++++++---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index d94d5ba414ee..27d91cfc3cd9 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -333,6 +333,28 @@ static void crng_fast_key_erasure(u8 key[CHACHA_KEY_SIZE],
memzero_explicit(first_block, sizeof(first_block));
}
+/*
+ * Return whether the crng seed is considered to be sufficiently
+ * old that a reseeding might be attempted. This is the case 5,
+ * 10, 20, 40, 80, and 160 seconds after boot, and after if the
+ * last reseeding was CRNG_RESEED_INTERVAL ago.
+ */
+static bool crng_has_old_seed(void)
+{
+ static unsigned int next_init_secs = 5;
+ unsigned int this_init_secs = READ_ONCE(next_init_secs);
+
+ if (unlikely(this_init_secs < CRNG_RESEED_INTERVAL / HZ)) {
+ unsigned int uptime = min_t(u64, INT_MAX, ktime_get_seconds());
+ if (uptime >= this_init_secs) {
+ WRITE_ONCE(next_init_secs, 5U << fls(uptime / 5));
+ return true;
+ }
+ return false;
+ }
+ return time_after(jiffies, READ_ONCE(base_crng.birth) + CRNG_RESEED_INTERVAL);
+}
+
/*
* This function returns a ChaCha state that you may use for generating
* random data. It also returns up to 32 bytes on its own of random data
@@ -366,10 +388,10 @@ static void crng_make_state(u32 chacha_state[CHACHA_STATE_WORDS],
}
/*
- * If the base_crng is more than 5 minutes old, we reseed, which
- * in turn bumps the generation counter that we check below.
+ * If the base_crng is old enough, we try to reseed, which in turn
+ * bumps the generation counter that we check below.
*/
- if (unlikely(time_after(jiffies, READ_ONCE(base_crng.birth) + CRNG_RESEED_INTERVAL)))
+ if (unlikely(crng_has_old_seed()))
crng_reseed(false);
local_lock_irqsave(&crngs.lock, flags);
--
2.35.1
next prev parent reply other threads:[~2022-03-10 21:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 15:26 [PATCH] random: reseed more often immediately after booting Jason A. Donenfeld
2022-03-09 19:18 ` [PATCH v2] " Jason A. Donenfeld
2022-03-10 4:57 ` Eric Biggers
2022-03-10 20:59 ` Jason A. Donenfeld
2022-03-10 21:10 ` Jason A. Donenfeld [this message]
2022-03-12 19:44 ` Eric Biggers
2022-03-13 0:35 ` Jason A. Donenfeld
2022-03-13 1:00 ` Eric Biggers
2022-03-13 1:29 ` Jason A. Donenfeld
2022-03-13 1:41 ` [PATCH v4] " Jason A. Donenfeld
2022-03-13 3:39 ` Eric Biggers
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=20220310211050.135078-1-Jason@zx2c4.com \
--to=jason@zx2c4.com \
--cc=ebiggers@google.com \
--cc=ebiggers@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=tytso@mit.edu \
/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