mirror of
https://git.proxmox.com/git/qemu-server
synced 2025-05-01 23:20:06 +00:00
2cf61f33d9
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@proxmox.com> |
||
|---|---|---|
| debian | ||
| PVE | ||
| qemu-configs | ||
| qmeventd | ||
| test | ||
| vm-network-scripts | ||
| .gitignore | ||
| bootsplash.jpg | ||
| bootsplash.xcf | ||
| Makefile | ||
| modules-load.conf | ||
| qm | ||
| qmextract | ||
| qmrestore | ||
