[pve-devel] [PATCH qemu-server 4/5] fix #2264: add virtio-rng device

[Stefan Reiter]

On 2/21/20 10:13 AM, Thomas Lamprecht wrote:
> Am 2/20/20 um 6:10 PM schrieb Stefan Reiter:
>> Allow a user to add a virtio-rng-pci (an emulated hardware random
>> number generator) to a VM with the rng0 setting. The setting is
>> version_guard()-ed.
>>
>> Limit the selection of entropy source to one of three:
>> /dev/urandom (preferred): Non-blocking kernel entropy source
>> /dev/random: Blocking kernel source
>> /dev/hwrng: Hardware RNG on the host for passthrough
>>
>> QEMU itself defaults to /dev/urandom (or the equivalent getrandom()
>> call) if no source file is given, but I don't fully trust that
>> behaviour to stay constant, considering the documentation [0] already
>> disagrees with the code [1], so let's always specify the file ourselves.
>>
>> /dev/urandom is preferred, since it prevents host entropy starvation.
>> The quality of randomness is still good enough to emulate a hwrng, since
>> a) it's still seeded from the kernel's true entropy pool periodically
>> and b) it's mixed with true entropy in the guest as well.
>>
>> Additionally, all sources about entropy predicition attacks I could find
>> mention that to predict /dev/urandom results, /dev/random has to be
>> accessed or manipulated in one way or the other - this is not possible
>> from a VM however, as the entropy we're talking about comes from the
>> *hosts* blocking pool.
>>
>> More about the entropy and security implications of the non-blocking
>> interface in [2] and [3].
>>
>> Note further that only one /dev/hwrng exists at any given time, if
>> multiple RNGs are available, only the one selected in
>> '/sys/devices/virtual/misc/hw_random/rng_current' will feed the file.
>> Selecting this is left as an exercise to the user, if at all required.
>>
>> We limit the available entropy to 1 KiB/s by default, but allow the user
>> to override this. Interesting to note is that the limiter does not work
>> linearly, i.e. max_bytes=1024/period=1000 means that up to 1 KiB of data
>> becomes available on a 1000 millisecond timer, not that 1 KiB is
>> streamed to the guest over the course of one second - hence the
>> configurable period.
>>
>> The default used here is the same as given in the QEMU documentation [0]
>> and has been verified to affect entropy availability in a guest by
>> measuring /dev/random throughput. 1 KiB/s is enough to avoid any
>> early-boot entropy shortages, and already has a significant impact on
>> /dev/random availability in the guest.
>>
>> [0] https://wiki.qemu.org/Features/VirtIORNG
>> [1] https://git.qemu.org/?p=qemu.git;a=blob;f=crypto/random-platform.c;h=f92f96987d7d262047c7604b169a7fdf11236107;hb=HEAD
>> [2] https://lwn.net/Articles/261804/
>> [3] https://lwn.net/Articles/808575/
>>
>> Signed-off-by: Stefan Reiter <s.reiter at proxmox.com>
>> ---
>>
>> Includes a version bump currently set to 4.1+pve2. Would need to be changed if
>> applied later.
> 
> Why?? This is a new option a user has explicit to set, either it's there or not.
> I'd bump the version just for every new option...
> 

Well, we fall back to the minimum necessary version anyway, so the 
version bump doesn't change anything if a user never uses the feature - 
but in case they do, they'll get a neat error message when attempting 
migration to older systems.

I think it makes sense and doesn't cost much to do, though it's 
certainly not necessary.