summary refs log tree commit diff stats
path: root/results/classifier/118/device/1811758
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/118/device/1811758')
-rw-r--r--results/classifier/118/device/181175854
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()
+