Re: [Xen-users] Re: dom0 and domU /dev/urandom generating too less entropy

[Robbie Dinn <robbie@microbus.com>]

Keir Fraser wrote:
> On 10/10/07 21:00, "Stephan Seitz" <s.seitz@netz-haut.de> wrote:
> 
>> Do you know about a workaround, or maybe the possibility for another
>> (xen-specific) RNG
>> besides of /dev/urandom ?
> 
> I'm surprised you see failures. By my understanding, /dev/urandom is always
> supposed to return the request number of bytes, but their randomness depends
> on the amount of entropy currently in the pool. Perhaps sshd explicitly
> interrogates urandom to find out how much entropy it has gathered?
I haven't checked (I am too laxy to strace it) but I believe that sshd
is using /dev/random not /dev/urandom. You can see how much entropy is
available by cat'ing /proc/sys/kernel/random/entropy_avail .
> 
> Anyway, the domU kernel gathers entropy from the interrupt delivery times of
> the netfront and blkfront drivers. This is similar to what a native kernel
> does. It's not clear how we can easily improve on that without e.g.,
> plumbing through a hardware RNG to domUs.

I had a similar problem on a mail server providing a pop3 service. Every
time a client machine connected to the pop3 daemon (cyrus imap actually),
it consumed entropy. More entropy was consumed for each connection
than was provided by the packets arriving. The machine ran of entropy
and stopped providing bytes via /dev/random. The pop3 daemon ground
to a halt because it was waiting to read bytes from /dev/random.

The work around was to feed entropy into the random number generator.
There is a user space tool to do this called 'rngd'.

The correct way to do this would be, as you say, to get the the entropy
from outside the domU. I used a dirty hack instead, I ran

/sbin/rngd --rng-device=/dev/urandom

Yes is wrong and evil but it got me up and running again.