Bug#897572: urandom hang in early boot
Ben Hutchings <ben@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
Reply to: