[PATCH RFC v0] random: block in /dev/urandom

[Lennart Poettering]

On Fr, 11.02.22 22:07, Jason A. Donenfeld (Jason at zx2c4.com) wrote:

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

So, systemd uses (potentially half-initialized) /dev/urandom for
seeding its hash tables. For that its kinda OK if the random values
have low entropy initially, as we'll automatically reseed when too
many hash collisions happen, and then use a newer (and thus hopefully
better) seed, again acquired through /dev/urandom. i.e. if the seeds
are initially not good enough to thwart hash collision attacks, once
the hash table are actually attacked we'll replace the seeds with
someting better. For that all we need is that the random pool
eventually gets better, that's all.

So for that usecase /dev/urandom behaving the way it so far does is
kinda nice. We need lots of hash tables, from earliest initialization
on, hence the ability to get some seed there reasonably fast is really
good, even if its entropy is initially not as high as we'd want. It's
a good middle ground for us to be able to boot up quickly and not
having to block until the entropy pool is fully initialized, but still
thwart hash table collision attacks.

If you make /dev/urandom block for initialization then this would mean
systemd and its components would start waiting for initialization
(simply because we need hash tables all over the place), i.e you'd
effectively add a second to the boot process of each affected system.

What about AT_RANDOM and /proc/sys/kernel/random/uuid btw, do you
intend to block for that too? If you block for the former it doesn't
really matter what systemd does I guess, given that you already have
to delay invoking PID 1 until you get a good AT_RANDOM.

Lennart

--
Lennart Poettering, Berlin