[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Robbie Dinn wrote:
> Keir Fraser wrote:
>> On 10/10/07 21:00, "Stephan Seitz" <s.seitz@xxxxxxxxxxxx> 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 .

No I am wrong. I did an strace of sshd and it does read /dev/urandom
not /dev/random as I claimed.

read(5, "\0\0\0\1\212\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"..., 752) = 752
open("/dev/urandom", O_RDONLY|O_NONBLOCK|O_NOCTTY) = 3
fstat64(3, {st_mode=S_IFCHR|0644, st_rdev=makedev(1, 9), ...}) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 10) = 1
read(3, "p:\326\232y\326f\364<#L\204(<\244\"\275,r\263\r%Z\f\304"..., 32) = 32
close(3)                                = 0

Sorry for the noise.

>> 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
s/machine ran of entropy/machine ran out 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.
s/Yes is wrong/Yes, it is wrong/

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.