The detail is covered in articles on lwn.net., search for RNG.

It’s worth reading here:
https://lwn.net/Articles/884875/

Some of the comments on /dev/random blocking aren’t quite correct for Fedora kernels in 37 and 38. 

Fun story: a couple jobs back we had a fancy documentation service on el5 that launched just fine in dev but would hang until a timeout killed it in prod. It was a big Java tomcat service and part of the initialization involved creating some session keys on startup, and when I attached it to a debugger, prod was hanging in the crypto libraries. I was able to watch the entropy pool drain in real-time by watching the file in/proc. 

Turns out, dev was a cluster of VMs in a VMware cluster that ran hundreds of other VMs, which ran on servers that had a lot of sources of entropy and fed that to the VMs. But Prod was a bunch of blades in an enclosure using fiber channel storage. They had a CPU that didn’t provide an entropy source. It had no keyboard or mouse, and the network wasn’t active until after the service started. The FC enclosure used disks that were SSDs that didn’t provide much of an entropy source. The Java crypto library (I want to say it was BouncyCastle?) was using a blocking /dev/random. 

Since we wanted the session keys to be more random, we decided not to use urandom , so a quick fix was it dd’ing the first couple hundred megabytes off the disk to /dev/null on boot, and eventually we got the haveged daemon feeding the entropy pool. Explaining why my hack worked was fun. 

--
Jonathan Billings