On Fr, 11.02.22 22:07, Jason A. Donenfeld (Jason@xxxxxxxxx) 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
