From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robbie Dinn Subject: Re: Re: [Xen-devel] dom0 and domU /dev/urandom generating too less entropy Date: Thu, 11 Oct 2007 16:28:29 +0100 Message-ID: <470E411D.6030207@microbus.com> References: <470E0CA4.4000909@microbus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <470E0CA4.4000909@microbus.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com To: Keir Fraser Cc: Stephan Seitz , XEN Devel - listmembers , XEN User - listmembers List-Id: xen-devel@lists.xenproject.org Robbie Dinn wrote: > Keir Fraser wrote: >> On 10/10/07 21:00, "Stephan Seitz" 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/