On Tue, Apr 5, 2022 at 7:10 AM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > > Practically speaking, this means that at least on x86, /dev/urandom > becomes safe. Probably other architectures with working cycle counters > will also become safe. And architectures with slow or broken cycle > counters at least won't be affected at all by this change. I think this is a good change, as it's a bit pointless to warn about uninitialized random data if we can just initialize it. I do wonder if it wouldn't be better to perhaps move this all into wait_for_random_bytes(), though, and add an argument to that function for "no delay". Because I think we should at the same time also add a warning to wait_for_random_bytes() for the "uhhhuh, it timed out". Right now wait_for_random_bytes() returns an error that most people then just ignore. Including drivers/net/wireguard/cookie.c. So instead of returning an error that nobody can do much about, how about we move the warning code into wait_for_random_bytes()? And make that urandom_read() call the same wait_for_random_bytes() that random_read() calls, just with GRND_NONBLOCK as an argument? Not a big deal. Your patch is fine by me too. Linus