[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
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
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.
Main Index |
Thread Index |