Ben Hutchings <b...@decadent.org.uk> writes: > On Tue, 2018-05-08 at 11:12 +1200, Ben Caradoc-Davies wrote: >> On 08/05/18 05:34, Laurent Bigonville wrote: >> > Apparently it's also happening for other applications that are starting >> > later during the boot like GDM. >> > Somebody has reported an issue on IRC where GDM was taking upto 8 >> > minutes to start (dmesg was showing several "random: systemd: >> > uninitialized urandom read (16 bytes read)" during boot) >> > That problem might impact lot of people I'm afraid. >> >> systemd is the underlying cause: plymouthd uses libudev1, which expects >> getrandom/urandom(?) to never block: >> https://github.com/systemd/systemd/blob/master/src/basic/random-util.c#L34 >> >> See discussion here about systemd usage of random numbers: >> systemd reads from urandom before initialization >> https://github.com/systemd/systemd/issues/4167 >> >> The new problem is that 43838a23a05f ("random: fix crng_ready() test") >> turns an ugly warning and cryptographic weakness into an indefinite >> hang. Security achieved! > > You keep saying this, but based on my reading of the code I don't see > how reads from /dev/urandom can end up blocking.
It's a bit convoluted, but if I read the code correctly then acquire_random_bytes() falls back to busy-loop reading from /dev/urandom until it has the requested number of bytes if 'high_quality_required' is true. There aren't more than two such calls, but one of then is sd_id128_randomize() which calls acquire_random_bytes(&t, sizeof t, true). And sd_id128_randomize() is called from all over the place. I haven't bothered looking at all the call sites, but would be surprised if not at least one of them is unconditionally called at boot. If I am correct, then I guess this is a systemd bug? Bjørn
