Re: [PATCH] random: allow writes to /dev/urandom to influence fast init

[Jason A. Donenfeld]

Hi all,

On Tue, Mar 22, 2022 at 10:47 PM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
> 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.

The plus side of doing all this is that, if the efforts pan out, it
means there'll actually be proper seeding on devices that don't
currently do that, which then might lead to a better ecosystem and
less boot time blocking and all that jazz.

Jason