Re: random(4) driver questions

[Alexander Clouter <alex@digriz.org.uk>]

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.