>
>> 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
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
