Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: regarding the changes to kernel entropy gathering

With some trepidation, I'm going to dip into this conversation even though I haven't read all of.  I don't have the mental fortitude for that. I have two suggestions, one short and one long.

Firstly, we could just have an rc.d script that checks to see if the system has /var/db/entropy-file or an rng device, and if not then it prints a warning and then generates some simplistic entropy with "ls -lR / ; dd if=/dev/urandom of=/dev/random bs=32 count=1 ; sysctl -w kern.entropy.consolidate=1". The system owner has been warned and the system proceeds to run.

Secondly we could fix what I see as the biggest problem with the new implementation that I see right now and that is that it is unreasonably difficult for people to work out how to make their system go forwards once it has stopped. Note that making the system go forwards is easy, it's work out what to do that's hard. We can fix that.

The current implementation prints out a message whenever it blocks a process that wants randomness, which immediately makes this implementation superior to all others that I have ever seen. The number of times I've logged into systems that have stalled on boot and made them finish booting by running "ls -lR /" over the past 20 years are too many to count. I don't know if I just needed to wait longer for the boot to finish, or if generating entropy was the fix, and I will never know. This is nuts.

We can use the message to point the system administrator to a manual page that tells them what to do, and by "tells them what to do", I mean in plain simple language, right at the top of the page, without scaring them.

How about this..

"entropy: pid %d (%s) blocking due to lack of entropy, see entropy(4)"

and then in entropy(4) we can start with something like

"If you are reading this because you have read a kernel message telling you that a process is blocking due to a lack of entropy then it is almost certainly because your hardware doesn't have a reliable source of randomness. If you have no particular requirements for cryptographic security on your system, you can generate some entropy and then tell the kernel that this entropy is 'enough' with the commands
    ls -lR /
    dd if=/dev/urandom of=/dev/random bs=32 count=1
    sysctl -w kern.entropy.consolidate=1
If have strong requirements for cryptographic security on your system then you should run 'rndctl -S /root/seed' on a system with hardware random number generate (most modern CPUs), copy the seed file over to this system as /var/db/entropy-file and then run 'rndctl -L /var/db/entropy-file'.

This only needs to be done once since scripts in rc.d will take care of saving and restoring system entropy in /var/db/entropy-file across reboots."

We could even do both of these things.

Home | Main Index | Thread Index | Old Index