From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1arx22-0005s6-ES for qemu-devel@nongnu.org; Sun, 17 Apr 2016 20:27:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1arx21-0006tg-Id for qemu-devel@nongnu.org; Sun, 17 Apr 2016 20:27:14 -0400 Received: from terminus.zytor.com ([2001:1868:205::10]:36998 helo=mail.zytor.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1arx21-0006tZ-CL for qemu-devel@nongnu.org; Sun, 17 Apr 2016 20:27:13 -0400 References: <5710C55E.3030000@redhat.com> <57110D27.6080805@redhat.com> <1627731.Y10g9rcVyf@pintsize.usersys.redhat.com> <1808605284.5070717.1460795498043.JavaMail.zimbra@redhat.com> From: "H. Peter Anvin" Message-ID: <571429D9.2090105@zytor.com> Date: Sun, 17 Apr 2016 17:27:05 -0700 MIME-Version: 1.0 In-Reply-To: <1808605284.5070717.1460795498043.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] RFC: virtio-rng and /dev/urandom List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Hubert Kario , Eric Blake , Cole Robinson , libvirt-list@redhat.com, qemu-devel , "Richard W.M. Jones" , "Daniel P. Berrange" , Peter Krempa , Amit Shah , mik@miknet.net, jjaburek@redhat.com, sgrubb@redhat.com On 04/16/16 01:31, Paolo Bonzini wrote: > > Right, but there's always the point about people that use heterogeneous > hosts and cannot pass rdrand/rdseed to the guest. For these, we should > add a QEMU driver that uses rdrand/rdseed, and thus decouples virtio-rng > from the host /dev/* completely. > > From the libvirt POV there are various possibilities: > > - Libvirt can have a libvirt.conf parameter that says "ignore whatever is > specified in the guest XML if rdrand/rdseed is available, and instead use > rdrand/rdseed". > > - Libvirt can allow specifying rdrand/rdseed _and_ an additional backend, > like this: > > > /dev/random > > and fallback to the second if rdrand/rdseed are not available. > The other thing, and this is one area where there is some legitimacy to the /dev/urandom argument: on a fresh boot, it would be highly desirable to get a seed value from virtio-rng even if that is "entropyless". The backwards-compatible way would be to provide, say, 64 bytes of /dev/urandom before switching to /dev/random, but it might be desirable to give the guest OS some way to cause that to reset, explicitly requesting a new seed after an in-VM guest reboot, kexec et al. This also ties into the proposed MSR to support kASLR in the guest in the absence of rdrand/rdseed. Using virtio in that phase of bootup is generally not feasible. -hpa