Random numbers in UEK5 and newer kernels are a LOT faster.
- The updated RNG is a lot quicker now, especially on multi-core CPUs (there is one RNG per CPU now).
- There’s no meaningful difference between /dev/random and /dev/urandom.
- You can keep running
rngdif it makes you feel good, but it’s no longer needed at all. - The
kernel.random.entropy_availsysctl is now effectively fixed at 256!
With the latest updates to UEK, including UEK5, UEK6 and UEK7, random numbers are now blazingly fast and seemingly never block. Historically, applications that asked for too many random numbers (reading /dev/random) would occasionally, and embarrassingly, just hang.
Getting this amazing performance from the kernel’s random number generator no longer requires running rngd either, all the logic to keep both /dev/random and /dev/urandom now live entirely in the kernel.
How is it possible?
In 2021, I talked about /dev/random no longer blocking in upstream Linux. That wasn’t the end of changes to the kernel’s random number generator (RNG), it was really only the beginning. Those changes have taken some time to get accepted and stabilized in upstream, but they now provide amazingly fast random numbers.
With the upstream random changes, entropy_avail is now effectively fixed at 256, even though /dev/random continues to generate random numbers at a rate of 250 to 400MB/s, or more, depending on the underlying processor. Even on a RaspberryPi4 it was around 160MB/s.
The fixed 256 value came from a commit in the 5.19 mainline kernel: e85c0fc1d94c (“random: do not pretend to handle premature next security model”) and that snappily titled commit is just one of the series of changes that was merged into 5.19 and it’s the end of a series of commits that started back in 5.17.
If you’re interested in the details (and who doesn’t like a bit of kernel crypto?) checkout Jason Donenfeld’s description of the 5.17 and 5.18 enhancements and the description for the 5.19 changes.
But my entropy pool is low? Don’t worry about it!
Recently a customer brought to my attention that the kernel.random.entropy_avail sysctl appeared to be worryingly low, even though rngd was running as we’d previously recommended. Without these changes, a “healthy” RNG’s entropy_avail would be around 3000 and many customers look specifically at that number to predict whether their applications might block. So don’t be shocked when a number that used to be in the 3000s is now permanently at 256, it’s by design.
You no longer need rngd and you no longer need to monitor entropy_avail either!
Can /dev/random still block if entropy is low?
No.
One of the changes in this series is to make /dev/random be almost like /dev/urandom. In fact for a while, the O_NONBLOCK option on opening /dev/random was ignored, but no one noticed for a couple of years. Eventually this was restored.
Reads to /dev/random and urandom can return EAGAIN, but only during early boot. Once a system is booted, it will never block again. You can see when this happens by looking for random: crng init done in the output of dmesg. The exact time varies a lot, it depends on how long it takes hardware to initialise, but it’s always before “switch root” when the OS changes from running in the initramfs to when it’s running in the normal file system and so long before any normal application can run.
Where to find these changes
The specific UEK versions where you can find the random improvements are in UEK7 (kernel-uek-5.15.0-2.52.3 August 2022), UEK6 (kernel-uek-5.4.17-2136.311.6, August 2022), and UEK5 (kernel-uek-4.14.35-2047.517.3, September 2022). The O_NONBLOCK behaviour in early boot was restored for all three UEK versions in December 2022 although, of course, that made no difference to normal applications.