On Fri, Dec 14, 2012 at 05:46:44PM +0100, Peter Krempa wrote: > Commit 16c915ba42b45df7a64a6908287f03bfa3764bed in the qemu.git tree > introduced support for emulating a virtio-rng device used to pass-through > entropy to the guests. > > Qemu provides two backends to gather entropy from: > 1) Default chardev backend > This backend supports reading non-blocking character devices that provide > entropy such as /dev/random (by default) or others according to > configuration. > > This backend also supports basic rate limiting of the entropy read from > the source. Unfortunately as the rate limiting is done just on a per-guest > basis this cannot protect the host from being starved of entropy by > multiple guests although their individual rates are limited. > > 2) EGD backend > This backend uses the EGD protocol to communicate with a daemon that > servers entropy. > > The EGD protocol is a simple protocol that was introduced by the entropy > gathering daemon (a substitute for /dev/random on machines that don't > support it). This protocol can be used for centralized management of > entropy allocation to the hosts. > > This by itself isn't really useful as implementations of EGD daemons are > trying to create the entropy instead of using available sources and > multiplexing/rate-limiting them. For this functionality we will (probably) > need a separate server to serve the entropy to the guests but more on this > topic later. > > To represent the configuration of the virtio-rng device to the guest I propose > the following domain XML snipped to be used: > > For the first use case I propose: > <domain> > [...] > <devices> > [...] > <rng model='virtio'> > <rate bytes='1024' period='1000'/> > <source type='char'>/dev/urandom</source> > -- or -- > <source type='char'/> > -- for the default source -- > </rng> > </devices> > </domain> > > For the EGD backend used manually (without any managed server) I propose: > <rng model='virtio'> > <rate bytes='1024' period='1000'/> > <source type='egd'> > <remote type='unix'>/path/to/socket</remote> > -- or -- > <remote type='tcp' port='12345'>host.addr</remote> > -- optionally or even more options, but they don't seem useful > </source> > </rng> > > > Now these solutions are mere envelopes on top of the qemu functionality and > don't really let us do any advanced configuration or management and they don't > protect the host or guests by themselves from starving others from entropy. > > The solution for the problem described above is to have a central point where > guests can request entropy and this central point will do all the rate > limiting. To do this we will need to add a daemon that will talk the EGD > protocol. This daemon will need to read entropy on request from the kernel > software entropy device (/dev/random) or possibly a hardware RNG and > distribute it to the hosts. > > To enable concurrent access and avoid starvation the daemon will implement a > "shaping protocol" based on the hierarchical token bucket approach used to > rate-limit network flows. For implementation details on this one I'll send a > separate RFC. > > To allow configuration of the groups and sources I propose to create a > separate driver with infrastructure similar to the network driver. This will > allow to start multiple entropy distribution daemons with different sources > and define the hierarchical classes to allow guest grouping. > > With this infrastructure you will be able to specify the rng device as > follows: > <rng model='virtio'> > <source type='pool' pool='default'>classname</source> > </rng> > > This will auto-configure all parameters according to the configuration of the > pool and ensure that te guest gets classified correctly. > > As the start I'll implement the two basic options and then I'll propose > another RFC how I will approach the second part more closely. This all sounds fairly sane to me. WRT the creation of a central daemon to support the EGD protocol, if you're not already planning this, I'd suggest that the daemon should be completely standalone. eg a virtrngd. As with virtlockd, we'll need virtrngd to be able to remain running even across RPM upgrades. So virtrngd will need to be able todo the same re-exec() magic that virtlockd does on RPM upgrades. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list