All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robbie Dinn <robbie@microbus.com>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Stephan Seitz <s.seitz@netz-haut.de>,
	XEN Devel - listmembers <xen-devel@lists.xensource.com>,
	XEN User - listmembers <xen-users@lists.xensource.com>
Subject: Re: Re: [Xen-devel] dom0 and domU /dev/urandom generating too less entropy
Date: Thu, 11 Oct 2007 16:28:29 +0100	[thread overview]
Message-ID: <470E411D.6030207@microbus.com> (raw)
In-Reply-To: <470E0CA4.4000909@microbus.com>

Robbie Dinn wrote:
> 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 .

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/

  reply	other threads:[~2007-10-11 15:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-10 20:00 dom0 and domU /dev/urandom generating too less entropy Stephan Seitz
2007-10-11  7:27 ` Keir Fraser
2007-10-11 11:44   ` [Xen-users] " Robbie Dinn
2007-10-11 15:28     ` Robbie Dinn [this message]
2007-10-11 16:10       ` Stephan Seitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=470E411D.6030207@microbus.com \
    --to=robbie@microbus.com \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=s.seitz@netz-haut.de \
    --cc=xen-devel@lists.xensource.com \
    --cc=xen-users@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.