From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRp7Q-0002BR-RB for qemu-devel@nongnu.org; Fri, 26 Oct 2012 14:58:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TRp7P-0008FD-Ma for qemu-devel@nongnu.org; Fri, 26 Oct 2012 14:58:56 -0400 Received: from mail-ea0-f173.google.com ([209.85.215.173]:35701) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TRp7P-0008F0-DW for qemu-devel@nongnu.org; Fri, 26 Oct 2012 14:58:55 -0400 Received: by mail-ea0-f173.google.com with SMTP id a1so1043690eaa.4 for ; Fri, 26 Oct 2012 11:58:54 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <508ADD66.5040909@redhat.com> Date: Fri, 26 Oct 2012 20:58:46 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <604401631.2277495.1351264128301.JavaMail.root@redhat.com> <871ugl44v5.fsf@codemonkey.ws> <508AB5C0.2000304@zytor.com> In-Reply-To: <508AB5C0.2000304@zytor.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/6] add paravirtualization hwrng support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "H. Peter Anvin" Cc: Amit Shah , Anthony Liguori , Andreas Faerber , qemu-devel@nongnu.org Il 26/10/2012 18:09, H. Peter Anvin ha scritto: > a) it means that the guest *has* to run rngd or a similar engine; if you > have control over the guests it might be more efficient to run rngd in > skip-test mode (I don't think that is currently implemented but it > could/should be) and centralize all testing to the host. > > A skip-test mode would also allow rngd to forward-feed shorter blocks > than 2500 bytes. That would be something we can communicate via virtio-rng-pci feature bits. Perhaps /dev/hwrng could also expose a need-whitening property in sysfs. > b) if the host has no physical hwrng, /dev/hwrng will output nothing at > all, which is worse than /dev/random in that situation. Not really, it would just mean that the guest takes more time to gather entropy, just like if you had no virtio-rng-pci at all. > If you have rdrand you might just use it in the guest directly, unless > you have a strong reason (migration?) not to do that. Either way, for > rdrand you need whitening similar to what rngd is doing (for *rdseed* > you do not, but rdseed is not shipping yet.) Yes, migration is a good reason. > The startup issue is an interesting problem. If you have full control > over the guest it might be best to simply inject some entropy into the > guest on startup via the initramfs or a disk image; that has its own > awkwardness too, of course. The one bit that could potentially be > solved in Qemu would be an option to "don't start the guest until X > bytes of entropy have been gathered." > > Overall, I want to emphasize that we don't want to try solve generic > problems in virtualization space... resource constraints on /dev/random > is a generic host OS issue for example. Yes, but the agreed solution right now is that programs should not ask for more than 32 bytes or so from /dev/random. Which means /dev/random is not a suitable backend for virtio-rng-pci as things stand now. Paolo