From: Eric Biggers <ebiggers@kernel.org>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-arch@vger.kernel.org, Dinh Nguyen <dinguyen@kernel.org>,
Nick Hu <nickhu@andestech.com>, Max Filippov <jcmvbkbc@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
"David S . Miller" <davem@davemloft.net>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Michal Simek <monstr@monstr.eu>, Borislav Petkov <bp@alien8.de>,
Guo Ren <guoren@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Joshua Kinard <kumba@gentoo.org>,
David Laight <David.Laight@aculab.com>,
Dominik Brodowski <linux@dominikbrodowski.net>,
Ard Biesheuvel <ardb@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Thomas Gleixner <tglx@linutronix.de>,
Andy Lutomirski <luto@kernel.org>,
Kees Cook <keescook@chromium.org>,
Lennart Poettering <mzxreary@0pointer.de>,
Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Theodore Ts'o <tytso@mit.edu>
Subject: Re: [PATCH v1] random: block in /dev/urandom
Date: Sat, 12 Mar 2022 12:27:13 -0800 [thread overview]
Message-ID: <Yi0CIRlY6/tDpjpf@sol.localdomain> (raw)
In-Reply-To: <Yiz/wm3nlJ/wOo6n@sol.localdomain>
On Sat, Mar 12, 2022 at 12:17:09PM -0800, Eric Biggers wrote:
> On Thu, Feb 17, 2022 at 05:28:48PM +0100, Jason A. Donenfeld wrote:
> > This topic has come up countless times, and usually doesn't go anywhere.
> > This time I thought I'd bring it up with a slightly narrower focus,
> > updated for some developments over the last three years: we finally can
> > make /dev/urandom always secure, in light of the fact that our RNG is
> > now always seeded.
> >
> > Ever since Linus' 50ee7529ec45 ("random: try to actively add entropy
> > rather than passively wait for it"), the RNG does a haveged-style jitter
> > dance around the scheduler, in order to produce entropy (and credit it)
> > for the case when we're stuck in wait_for_random_bytes(). How ever you
> > feel about the Linus Jitter Dance is beside the point: it's been there
> > for three years and usually gets the RNG initialized in a second or so.
> >
> > As a matter of fact, this is what happens currently when people use
> > getrandom(). It's already there and working, and most people have been
> > using it for years without realizing.
> >
> > So, given that the kernel has grown this mechanism for seeding itself
> > from nothing, and that this procedure happens pretty fast, maybe there's
> > no point any longer in having /dev/urandom give insecure bytes. In the
> > past we didn't want the boot process to deadlock, which was
> > understandable. But now, in the worst case, a second goes by, and the
> > problem is resolved. It seems like maybe we're finally at a point when
> > we can get rid of the infamous "urandom read hole".
> >
> > The one slight drawback is that the Linus Jitter Dance relies on random_
> > get_entropy() being implemented. The first lines of try_to_generate_
> > entropy() are:
> >
> > stack.now = random_get_entropy();
> > if (stack.now == random_get_entropy())
> > return;
> >
> > On most platforms, random_get_entropy() is simply aliased to get_cycles().
> > The number of machines without a cycle counter or some other
> > implementation of random_get_entropy() in 2022, which can also run a
> > mainline kernel, and at the same time have a both broken and out of date
> > userspace that relies on /dev/urandom never blocking at boot is thought
> > to be exceedingly low. And to be clear: those museum pieces without
> > cycle counters will continue to run Linux just fine, and even
> > /dev/urandom will be operable just like before; the RNG just needs to be
> > seeded first through the usual means, which should already be the case
> > now.
> >
> > On systems that really do want unseeded randomness, we already offer
> > getrandom(GRND_INSECURE), which is in use by, e.g., systemd for seeding
> > their hash tables at boot. Nothing in this commit would affect
> > GRND_INSECURE, and it remains the means of getting those types of random
> > numbers.
> >
> > This patch goes a long way toward eliminating a long overdue userspace
> > crypto footgun. After several decades of endless user confusion, we will
> > finally be able to say, "use any single one of our random interfaces and
> > you'll be fine. They're all the same. It doesn't matter." And that, I
> > think, is really something. Finally all of those blog posts and
> > disagreeing forums and contradictory articles will all become correct
> > about whatever they happened to recommend, and along with it, a whole
> > class of vulnerabilities eliminated.
> >
> > With very minimal downside, we're finally in a position where we can
> > make this change.
> >
> > Cc: Dinh Nguyen <dinguyen@kernel.org>
> > Cc: Nick Hu <nickhu@andestech.com>
> > Cc: Max Filippov <jcmvbkbc@gmail.com>
> > Cc: Palmer Dabbelt <palmer@dabbelt.com>
> > Cc: David S. Miller <davem@davemloft.net>
> > Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> > Cc: Michal Simek <monstr@monstr.eu>
> > Cc: Borislav Petkov <bp@alien8.de>
> > Cc: Guo Ren <guoren@kernel.org>
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: Joshua Kinard <kumba@gentoo.org>
> > Cc: David Laight <David.Laight@aculab.com>
> > Cc: Dominik Brodowski <linux@dominikbrodowski.net>
> > Cc: Eric Biggers <ebiggers@google.com>
> > Cc: Ard Biesheuvel <ardb@kernel.org>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Andy Lutomirski <luto@kernel.org>
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: Lennart Poettering <mzxreary@0pointer.de>
> > Cc: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Theodore Ts'o <tytso@mit.edu>
> > Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> > ---
> > Having learned that MIPS32 isn't affected by this (initially my largest
> > worry), and then heartened today upon reading LWN's summary of our
> > previous discussion ("it would seem there are no huge barriers to
> > removing the final distinction between /dev/random and /dev/urandom"), I
> > figured I'd go ahead and submit a v1 of this. It seems at least worth
> > trying and seeing if somebody arrives with legitimate complaints. To
> > that end I've also widened the CC list quite a bit.
> >
> > Changes v0->v1:
> > - We no longer touch GRND_INSECURE at all, in anyway. Lennart (and to an
> > extent, Andy) pointed out that getting insecure numbers immediately at
> > boot is still something that has legitimate use cases, so this patch
> > no longer touches that code.
> >
> > drivers/char/mem.c | 2 +-
> > drivers/char/random.c | 51 ++++++------------------------------------
> > include/linux/random.h | 2 +-
> > 3 files changed, 9 insertions(+), 46 deletions(-)
> >
>
> Just a small nit: the comments above rng_is_initialized() and
> wait_for_random_bytes() still imply that /dev/urandom is nonblocking.
>
Also the comment describing 'Fast key erasure RNG, the "crng".' still claims
that get_random_bytes(), get_random_u32(), etc. are "equivalent to a read from
/dev/urandom". With this patch, they're not, since they don't block whereas
/dev/urandom will block.
- Eric
next prev parent reply other threads:[~2022-03-12 20:27 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-17 16:28 [PATCH v1] random: block in /dev/urandom Jason A. Donenfeld
2022-02-21 18:01 ` Andy Lutomirski
2022-02-23 17:02 ` Jason A. Donenfeld
2022-02-23 17:55 ` Theodore Ts'o
2022-03-12 20:17 ` Eric Biggers
2022-03-12 20:27 ` Eric Biggers [this message]
2022-03-22 15:58 ` Guenter Roeck
2022-03-22 16:21 ` Linus Torvalds
2022-03-22 16:40 ` Jason A. Donenfeld
2022-03-22 17:09 ` Jason A. Donenfeld
2022-03-22 17:56 ` Guenter Roeck
2022-03-22 18:19 ` Jason A. Donenfeld
2022-03-22 18:29 ` Linus Torvalds
2022-03-22 18:36 ` Jason A. Donenfeld
2022-04-22 13:42 ` Jason A. Donenfeld
2022-04-22 23:46 ` Guenter Roeck
2022-04-23 13:56 ` Guenter Roeck
2022-04-23 14:28 ` Jason A. Donenfeld
2022-04-23 16:35 ` Guenter Roeck
2022-04-23 21:10 ` Jason A. Donenfeld
2022-04-24 2:04 ` Guenter Roeck
2022-04-25 0:12 ` Jason A. Donenfeld
2022-04-25 1:54 ` Guenter Roeck
2022-04-25 11:11 ` Jason A. Donenfeld
2022-03-22 18:24 ` Mark Brown
2022-03-22 21:54 ` Guenter Roeck
2022-03-22 22:25 ` David Laight
2022-03-23 12:10 ` Mark Brown
2022-03-23 14:23 ` Guenter Roeck
2022-03-23 15:53 ` Arnd Bergmann
2022-03-23 16:18 ` Mark Brown
2022-03-23 16:41 ` Arnd Bergmann
2022-03-23 16:47 ` Mark Brown
2022-04-23 0:52 ` Jason A. Donenfeld
2022-04-25 12:09 ` Mark Brown
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=Yi0CIRlY6/tDpjpf@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=David.Laight@aculab.com \
--cc=Jason@zx2c4.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=davem@davemloft.net \
--cc=dinguyen@kernel.org \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=guoren@kernel.org \
--cc=jcmvbkbc@gmail.com \
--cc=keescook@chromium.org \
--cc=konstantin@linuxfoundation.org \
--cc=kumba@gentoo.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=luto@kernel.org \
--cc=monstr@monstr.eu \
--cc=mzxreary@0pointer.de \
--cc=nickhu@andestech.com \
--cc=palmer@dabbelt.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=ysato@users.sourceforge.jp \
/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).