Proposed F19 Feature: Virtio RNG

[Cole Robinson]

amit's response:

On (Sun) 03 Feb 2013 [10:30:49], Cole Robinson wrote:
> 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.

That's right.

>> 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.)

1. The host has more sources of entropy than a single guest -- it has
   more network and disk activity going on due to all the guests,
   contributing to the host's entropy pool

2. qemu has an option to rate-limit the amount of data sent to a
   single guest, so any one guest won't starve other guests as well as
   the host of entropy.

However, having only one physical hwrng in the host scales much better
than having one for each VM, so it's expected server admins will have
one hwrng.  Newer Intel processors have the RDRAND instruction, which
is an endless supply of entropy as well.

> 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.

I sure hope virtio-rng is made a default device -- always having high-quality
entropy when randomness is needed is always preferable.  Not now,
though -- maybe in a couple of releases (when we have the RDRAND
backend in qemu, and the new Intel CPUs are readily available).

> 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

The qemu feature page has info on qemu's options for rate-limiting.
However, qemu doesn't have knowledge of the entire host -- how many
guests exist, how many guests are asking for entropy, and at what
rate, etc.  libvirt has that info, and can provide a fair sharing of
the host's entropy among all the guests and the host itself.

>> 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.

Studies show even feeding host's /dev/urandom to guests is sufficient
and even if the host doesn't receive fresh entropy for several years,
all the guests and the host will be fine.  However, /dev/urandom is a
very poor source of entropy to feed into guests (it's a PRNG, not a
DRNG that a guest's hwrng input expects), so we never use the host's
/dev/urandom to send data to the guest.  Using host's /dev/random is
much better, but using a real hwrng or RDRAND on the host are the
optimal solutions.  The choice of input sources to feed in to the
guest rests on the admin, but the default of /dev/random is not going
to invalidate any certification.

Additionally, if a guest is rate-limited for entropy for some reason,
like starving the host itself, it won't be much worse-off than without
the virtio-rng.  So only the source of the entropy is a concern for
certification, and from what I know, we're fine with the defaults that
qemu provides.

		Amit