From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O5bDT-0003CB-5t for qemu-devel@nongnu.org; Sat, 24 Apr 2010 04:59:59 -0400 Received: from [140.186.70.92] (port=38466 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5bDQ-0003Ak-EB for qemu-devel@nongnu.org; Sat, 24 Apr 2010 04:59:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O5bDK-0001lZ-A9 for qemu-devel@nongnu.org; Sat, 24 Apr 2010 04:59:55 -0400 Received: from bhuna.collabora.co.uk ([93.93.128.226]:50485) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O5bDK-0001lA-0Q for qemu-devel@nongnu.org; Sat, 24 Apr 2010 04:59:50 -0400 Message-ID: <4BD2B2B7.9090308@collabora.co.uk> Date: Sat, 24 Apr 2010 09:58:31 +0100 From: Ian Molton MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 2/2] VirtIO RNG References: <4BCE061B.2030506@collabora.co.uk> <20100420205654.GI11723@shareable.org> <4BCE1D3B.7000306@collabora.co.uk> <4BCEAC99.8000206@redhat.com> <20100421094007.GC13114@shareable.org> <4BCEF0B9.2050704@collabora.co.uk> <4BCF03D2.5000307@redhat.com> <4BD09E3F.7070605@collabora.co.uk> <20100422210542.GB13951@shareable.org> <4BD173A1.9080104@collabora.co.uk> <20100424013708.GC15349@shareable.org> In-Reply-To: <20100424013708.GC15349@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Paul Brook , qemu-devel@nongnu.org, Gerd Hoffmann On 24/04/10 02:37, Jamie Lokier wrote: > Ian Molton wrote: >> Jamie Lokier wrote: >>> First of all: Why are your egd daemons with open connections dying >>> anyway? Buggy egd? >> >> No, they aren't buggy. but occasionally, the sysadmin of said server >> farms may want to, you know, update the daemon? > > Many daemons don't kill active connections on upgrade. For example > sshd, telnetd, ftpd, rsyncd... Only new connections get the new daemon. Thats actually completely irrelevant, but ok. > But let's approach this from a different angle: Oh god, not again... > What do _other_ long-lived EGD clients do? Is it: > > 1. When egd is upgraded, the clients break. I'm sure some do this. > 3. Active connections aren't killed on egd upgrade. I don't know of any egd servers that are that nice. > 2. They keep trying to reconnect, as you've implemented in qemu. Some do. > 4. Whenever they want entropy, they're expected to open a > connection, request what they want, read it, and close. Each time. Some do that too. > Whatever other long-lived clients do, that's probably best for qemu > too. Well clearly thats going to be inconclusive. > 4 is interesting because it's an alternative approach to rate-limiting > the byte stream: Instead, fetch a batch of bytes in a single > open/read/close transaction when needed. Rate-limit _that_, and you > don't need separate reconnection code. You're effectively talking about idle-disconnect. It's not actually a bad idea, but we still need reconnect support in some form, in case the server goes away mid-fetch. > So I trying checking if egd kills connections when upgraded, and found... > > No 'egd' package for my Debian and Ubuntu systems, nor anything which > looks obvious. There are several other approaches to gathering > entropy from hardware sources, for example rng-tools, haveged, ekeyd, and > ekeyd-egd-linux (aha... it's a client). ekeyd is an EGD server. > All of those have in common: they fetch entropy from something, and > write it to the kernel's /dev/random pool. Applications are expected > to read from that pool. Um. no. Applications *can* read that pool. Its not the only way, and designing apps that can ONLY do that is forcing policy. > In particular, if you do have a hardware or network EGD entropy > source, you can run ekeyd-egd-linux which is an EGD client, which > transfers from EGD -> the kernel, so that applications can read from > /dev/random. You *can* - but what if you have two entropy sources and you dont want the guests sucking down entropy from the hosts source, only their shared source? > That means, on Debian& Ubuntu Linux at least, there is no need for > applications to talk EGD protocol themselves, even to get network or > hardware entropy - it's better left to egd-linux, rng-tools etc. to > manage. And if you don't use Debian or Ubuntu, or you install your own package (you can use non-packaged software, and all...) > But the situation is no doubt different on non-Linux hosts. Indeed. /dev/random doesn't even exist on many hosts. > By the way, ekeyd-egd-linux is a bit thoughtful: For example it has a > "shannons-per-byte" option, and it doesn't drain the EGD server at all > when the local pool is sufficiently full. Indeed it is. I happen to be working with the folks that wrote it, as it happens. > Does your EGD client + virtio-rng support do that - avoid draining the > source when the guest's pool is full enough? Actually yes, although that involves trusting the guest, which is the reason why my implementation has its own rate limiting - to prevent guest abuse of the hosts pool. >>> If guests need a _reliable_ source of data for security, silently not >>> complaining when it's gone away and hoping it comes back isn't good >>> enough. >> >> Why? its not like the guest: >> >> a) Has a choice in the matter >> b) Would carry on without the entropy (it knows it has no entropy) > > Because one might prefer a big red light, a halted machine removed > from the cluster which can resume its work when ready, and an email to > warn you that the machine isn't able to operate normally _without_ > having to configure each guest's email, rather than a working machine > with increasing numbers of stuck crypto processes waiting on > /dev/random which runs out of memory and after getting into swap hell, > you have to reboot it, losing the other work that it was in the > middle of doing. > > Well, you personally might not prefer that. But that's why we > separate policy from mechanism... Thats something of a doomsday scenario, but hey - if you like having QMP support, feel free to add it to the patch - thats what open source is all about, right? > virtio-serial isn't emulating a normal serial port. It supports apps > like "send machine status blobs regularly", without having to be > robust against half a blob being delivered. > > You can design packets so that doesn't matter, but virtio-serial > supports not needing to do that, making the apps simpler. Have you actually read the code? virtio-rng is FAR simpler than virtio-serial. >>> I don't think it'll happen. I think egd is a rather unusual >>> If another backend ever needs it, it's easy to move code around. >> >> *bangs head on wall* >> >> That was the exact same argument I made about the rate limiting code. >> Why is that apparently only valid if its not me that says it? > > Because you're talking to multiple people who hold different opinions, > and opinions change as more is learned and thought about. Round in circles, apparently. This is getting on for the fourth time round... > Ah, that's not quite what I meant. I meant I wasn't convinced it is > needed for egd, not I don't think anyone should use egd. (But now I > see that egd-linux has a "reconnect time" option, perhaps reconnecting > _is_ de facto part of EGD protocol.) Actually EGD is very much an ad-hoc standard I'm afraid. But it does exist, and my implementation both works, and is compliant with the standard, such as it is. > But now that we've confirmed that on Debian& Ubuntu, all hardware > entropy sources are injected into /dev/random by userspace daemons > rather than serving EGD protocol, No, we know that they *can be* not that they are, and not even by default - you actually have to elect to install a package to do that. > and if you do have an EGD server you > can run egd-linux and apps can read /dev/random, and egd-linux won't > drain the EGD server unnecessarily... If you want the entropy to enter the *hosts* pool then sure - but I thought we weren't about forcing policy on the users? > are you sure EGD support is appropriate? Yes. Its what the users want. Its not broken or inefficient. Therefore its appropriate. > Is it different on, say, Fedora? Or are you thinking of > other hosts? There do exist hosts with no /dev/random as it happens. -Ian