On 02/01/2013 04:39 PM, Bill Nottingham wrote: > Jaroslav Reznik (jreznik@xxxxxxxxxx) said: >> Feature owner(s): Cole Robinson <crobinso@xxxxxxxxxx>, Amit Shah >> <amit.shah@xxxxxxxxxx> >> >> Provide a paravirtual random number generator to virtual machines, to prevent >> entropy starvation in guests. >> >> == Detailed description == >> The linux kernel collects entropy from various non-deterministic hardware >> events, like mouse and keyboard input, and network traffic. This entropy is then >> exposed through /dev/random, commonly used by cryptographic applications that >> need true randomness to maintain security. However if more entropy is being >> consumed than is being produced, we have entropy starvation: reading from >> /dev/random will block, which can cause a denial of service. A common example >> here is use of /dev/random by SSL in various services. >> >> VirtIO RNG (random number generator) is a paravirtualized device that is >> exposed as a hardware RNG device to the guest. Virtio RNG just appears as a >> regular hardware RNG to the guest, which the kernel reads from to fill its >> entropy pool. This effectively allows a host to inject entropy into a guest via >> several means: The default mode uses the host's /dev/random, but a physical HW >> RNG device or EGD (Entropy Gathering Daemon) source can also be used. > Amit can give more authoritative answers, but here's my understanding: > What exactly feeds /dev/random in the guest in the cases where this doesn't > exist, Same things that feed entropy on a physical machine: VM keyboard + mouse movement, VM hardware events, etc. The entropy starvation risk isn't much different for a headless server VM than for a headless server physical machine, AIUI. > and how do we cope with this obviously making /dev/random exhaustion > in the host much more likely? (Other than assume that a HW RNG is in the > host.) > The default mode of pulling from host /dev/random certainly does not scale unless there's something feeding your host's entropy pool. And this won't be enabled by default, just new opt in functionality. I think anyone with a non-trivial setup and need for more entropy in their guests will use this to share a single hwrng or a more involved setup with EGD. Peter Krempa, who is implementing the libvirt side of things, had some ideas about a virt entropy daemon that could do more advanced rate limiting to stave off entropy exhaustion across hosts/guests: https://www.redhat.com/archives/libvir-list/2012-December/msg00937.html > Given FIPS paranoia about RNG sources, does this have knock-on effects in > the FIPS compliance of guests depending on how it's fed in the host? No clue about that, I've added that to the comments section of the feature page. Thanks, cole -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
