Proposed F19 Feature: Virtio RNG

[Cole Robinson]

On 02/01/2013 04:39 PM, Bill Nottingham wrote:
> Jaroslav Reznik (jreznik at redhat.com) said: 
>> Feature owner(s): Cole Robinson <crobinso at redhat.com>, Amit Shah 
>> <amit.shah at redhat.com>
>>
>> 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