diff options
Diffstat (limited to 'results/classifier/118/device/1811758')
| -rw-r--r-- | results/classifier/118/device/1811758 | 54 |
1 files changed, 54 insertions, 0 deletions
diff --git a/results/classifier/118/device/1811758 b/results/classifier/118/device/1811758 new file mode 100644 index 000000000..128ded27c --- /dev/null +++ b/results/classifier/118/device/1811758 @@ -0,0 +1,54 @@ +device: 0.828 +performance: 0.811 +semantic: 0.731 +network: 0.726 +architecture: 0.714 +ppc: 0.669 +files: 0.661 +mistranslation: 0.656 +PID: 0.650 +hypervisor: 0.645 +vnc: 0.644 +kernel: 0.641 +socket: 0.639 +user-level: 0.634 +register: 0.596 +peripherals: 0.581 +permissions: 0.537 +graphic: 0.513 +risc-v: 0.470 +virtual: 0.445 +x86: 0.429 +boot: 0.395 +VMM: 0.383 +arm: 0.379 +i386: 0.375 +TCG: 0.310 +KVM: 0.295 +assembly: 0.237 +debug: 0.201 + +virtio-rng backend should use getentropy() syscall when available + +According to https://wiki.qemu.org/Features/VirtIORNG the default backend for `virtio-rng-pci` is `/dev/random`. Alternately, the user can point it to a different backend file, like `/dev/urandom`. + +However, both of these files have suboptimal behavior in one way or another, as documented in `random(7)`. Instead, the default behavior should be to pull the requested octets from the `getrandom()` system call, if available, called with no flags set. + +To be clear, the problem with using /dev/urandom as a backend is that it's possible to feed data from an uninitialized pool into the guest. + +and the problem with using /dev/random as a backend is that it's possible for a guest to starve the other host (and other guests) of entropy, since it pulls from the blocking pool. + +getrandom() only blocks when the CSPRNG is not initialized, otherwise it never blocks. this is the right behavior by default. + +any word on this? If this is not considered for adoption, i would like to know the reason, so that we can have better predictions about what to do for entropy in a QEMU system. + +Feel free to send some patches to implement this! Alternatively, you could also try to write a mail to the virtio-rng maintainer (see the MAINTAINER file in the top directory of the sources), maybe he can help. + +Yes, using getrandom() in qemu by default on systems that support it will be an improvement, and is the right approach. + +rng-builtin is the new RNG default backend for virtio-rng and is based on getrandom(). + +0198c2621a1e virtio-rng: change default backend to rng-builtin +5f7655f6ef15 virtio-rng: Keep the default backend out of VirtIORNGConf +6c4e9d487fea rng-builtin: add an RNG backend that uses qemu_guest_getrandom() + |