Messages in this thread | | | From | Alexander Clouter <> | Subject | Re: random(4) driver questions | Date | Sat, 25 Jun 2011 13:53:59 +0100 |
| |
Sandy Harris <sandyinchina@gmail.com> wrote: > > One problem they pointed out is that there may be little entropy > available on a Linux-based router; no keyboard or mouse, solid state > storage so no disk entropy, and an enemy might observe network > activity, so network interrupts give little or no useful entropy. > I vaguely recall network interrupts (anything that can be externally influenced) can be snooped upon so their use is discouraged. Turns out IRQF_SAMPLE_RANDOM is scheduled for destruction, Documentation/feature-removal-schedule.txt.
> The only in-kernel solution I can think of would be to add something > in the system call interface to make very system call throw timing > information into the pool. I very much doubt, though, that that is a > good idea. What do others think, and does anyone have a better idea? > An option I used, no idea if it safe though, for my headless colo box that seemed to always be running out of entropy was use a sleep() timing daemon:
http://www.vanheusden.com/te/
There was no chance of me using the ALSA/video4linux approach also on that site as I had a SPARC server so it was my only real choice. Seems to work well, but had to apply a patch to stop it insanely spinning the CPU un-necessarily (the author unfortunately never responded):
http://stuff.digriz.org.uk/timer-select.diff
Another tool I found in my travels was HAVEGE:
http://www.irisa.fr/caps/projects/hipsor/index.php
Again, no idea if this is a good idea.
Of course in the VM world, the timer approach probably would work.
Cheers
-- Alexander Clouter .sigmonster says: Some people only open up to tell you that they're closed.
| |