Linux To Try To Opportunistically Initialize /dev/urandom

Linux 5.18 is bringing many random/RNG improvements thanks to the work of kernel developer Jason Donenfeld. One of the changes though that had to be backed out during the merge window was trying to get /dev/random and /dev/urandom to behave exactly the same. While reverted for now with the 5.18 code, Donenfeld has prepared a change that should get it into good shape for major architectures with the next kernel cycle.

That unifying of /dev/random and /dev/urandom work had to be backed out due to some CPU architectures not having enough source of randomness at boot and no jitter entropy. This was causing problems for Arm (32-bit), Motorola 68000 (M68k), Microblaze, SPARX32, Xtensa, and other niche architectures.

With this patch now in the random.git development tree, it's trying to opportunistically initialize on /dev/urandom reads. For major, prominent architectures this should allow the same behavior as was desired with the Linux 5.18 RNG changes around urandom.

In 6f98a4bfee72 ("random: block in /dev/urandom"), we tried to make a successful try_to_generate_entropy() call *required* if the RNG was not already initialized. Unfortunately, weird architectures and old userspaces combined in TCG test harnesses, making that change still not realistic, so it was reverted in 0313bc278dac ("Revert "random: block in /dev/urandom"").

However, rather than making a successful try_to_generate_entropy() call *required*, we can instead make it *best-effort*.

If try_to_generate_entropy() fails, it fails, and nothing changes from the current behavior. If it succeeds, then /dev/urandom becomes safe to use for free. This way, we don't risk the regression potential that led to us reverting the required-try_to_generate_entropy() call before.

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.

So it may not be the glorious "all things are unified!" change we were hoping for initially, but practically speaking, it makes a positive impact.

Assuming no further RNG issues uncovered with this work, you can expect to find this change appear in the Linux 5.19 kernel this summer.

Update: It appears now that the change is being submitted as a pull request for Linux 5.18 as a "fix"... We'll see if this change gets honored this time still for 5.18 or is diverted to 5.19.