All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: "Alex Xu (Hello71)" <alex_y_xu@yahoo.ca>,
	Jann Horn <jannh@google.com>,
	Dominik Brodowski <linux@dominikbrodowski.net>,
	Guenter Roeck <linux@roeck-us.net>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Theodore Ts'o <tytso@mit.edu>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] random: allow writes to /dev/urandom to influence fast init
Date: Sun, 19 Jun 2022 18:44:16 +0200	[thread overview]
Message-ID: <20220619164416.GA3362@bug> (raw)
In-Reply-To: <CAHmME9ovJpdcuuZhNKrOTUc8XvKDDdC+axhAmOD9iESnRR7JqA@mail.gmail.com>

Hi!

> > Very much so, thanks again. What I take away from your results is:
> >
> > - RNDADDTOENTCNT is in active use in a safe way. Sure, RNDADDENTROPY
> > is still much better, but RNDADDTOENTCNT isn't entirely broken in the
> > above configurations either.
> > - This patch would make RNDADDTOENTCNT unsafe for some of the above
> > configurations in a way that it currently isn't unsafe.
> > - Plenty of things are seeding the RNG correctly, and buildroot's
> > shell script is just "doing it wrong".
> >
> > On that last point, I should reiterate that buildroot's shell script
> > still isn't actually initializing the RNG, despite what it says in its
> > echo; there's never been a way to initialize the RNG from a shell
> > script, without calling out to various special purpose ioctl-aware
> > binaries.
> 
> Based on this, the fact that shell scripts cannot seed the RNG anyway,
> and due to the hazards in trying to retrofit some heuristics onto an
> interface that was never designed to work like this, I'm convinced at
> this point that the right course of action here is to leave this
> alone. There's no combination of /dev/urandom write hacks/heuristics
> that do the right thing without creating some big problem elsewhere.
> It just does not have the right semantics for it, and changing the
> existing semantics will break existing users.
> 
> In light of that conclusion, I'm going to work with every userspace
> downstream I can find to help them fix their file-based seeding, if it
> has bugs. I've started talking with the buildroot folks, and then I'll
> speak with the OpenRC people (being a Gentoo dev, that should be easy
> going). Systemd does the right thing already.
> 
> I wrote a little utility for potential inclusion in
> busybox/util-linux/whatever when it matures beyond its current age of
> being half hour old:
> - https://git.zx2c4.com/seedrng/about/
> - https://git.zx2c4.com/seedrng/tree/seedrng.c
> So I'll see what the buildroot people think of this and take it from there.

You could put it into the kernel into tools/ directory...

Best regards,
									Pavel

  parent reply	other threads:[~2022-06-19 16:44 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-22 19:14 [PATCH] random: allow writes to /dev/urandom to influence fast init Jason A. Donenfeld
2022-03-22 20:42 ` Linus Torvalds
2022-03-22 23:54   ` Jason A. Donenfeld
2022-03-23  2:15 ` David Laight
2022-03-23  2:50   ` Jason A. Donenfeld
2022-03-23  8:43     ` Rasmus Villemoes
2022-03-24 14:12       ` Jason A. Donenfeld
2022-03-23 11:45     ` David Laight
2022-03-23  3:35 ` Theodore Ts'o
2022-03-23  4:00   ` Jason A. Donenfeld
2022-03-23 12:31     ` Theodore Ts'o
2022-05-23 17:59     ` Pavel Machek
2022-03-23  4:30 ` Alex Xu (Hello71)
2022-03-23  4:47   ` Jason A. Donenfeld
2022-03-23 14:01     ` David Laight
2022-03-23 19:53       ` Jason A. Donenfeld
2022-03-24 18:01         ` Eric Biggers
2022-03-24  3:18     ` Jason A. Donenfeld
2022-03-24 16:28       ` Alex Xu (Hello71)
2022-03-24 17:20         ` Jason A. Donenfeld
2022-03-24 19:03           ` Alex Xu (Hello71)
2022-03-24 18:26       ` Eric Biggers
2022-03-24 18:31         ` Jason A. Donenfeld
2022-06-19 16:44       ` Pavel Machek [this message]
2022-03-24 19:53 ` Eric Biggers
2022-03-24 20:25   ` Jason A. Donenfeld
2022-06-19 16:56     ` Pavel Machek

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=20220619164416.GA3362@bug \
    --to=pavel@ucw.cz \
    --cc=Jason@zx2c4.com \
    --cc=alex_y_xu@yahoo.ca \
    --cc=jannh@google.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=linux@roeck-us.net \
    --cc=torvalds@linux-foundation.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.