Re: regarding the changes to kernel entropy gathering

[Lloyd Parkes <lloyd%must-have-coffee.gen.nz@localhost>]

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.