Kashyap Chamarthy <[email protected]> writes: > When QEMU exposes a VirtIO-RNG device to the guest, that device needs a > source of entropy, and that source needs to be "non-blocking", like > `/dev/urandom`. However, currently QEMU defaults to the problematic > `/dev/random`, which is "blocking" (as in, it waits until sufficient > entropy is available). > > Why prefer `/dev/urandom` over `/dev/random`? > --------------------------------------------- > > The man pages of urandom(4) and random(4) state: > "The /dev/random device is a legacy interface which dates back to a > time where the cryptographic primitives used in the implementation > of /dev/urandom were not widely trusted. It will return random > bytes only within the estimated number of bits of fresh noise in the > entropy pool, blocking if necessary. /dev/random is suitable for > applications that need high quality randomness, and can afford > indeterminate delays." > > Further, the "Usage" section of the said man pages state: > > "The /dev/random interface is considered a legacy interface, and > /dev/urandom is preferred and sufficient in all use cases, with the > exception of applications which require randomness during early boot > time; for these applications, getrandom(2) must be used instead, > because it will block until the entropy pool is initialized. > > "If a seed file is saved across reboots as recommended below (all > major Linux distributions have done this since 2000 at least), the > output is cryptographically secure against attackers without local > root access as soon as it is reloaded in the boot sequence, and > perfectly adequate for network encryption session keys. Since reads > from /dev/random may block, users will usually want to open it in > nonblocking mode (or perform a read with timeout), and provide some > sort of user notification if the desired entropy is not immediately > available." > > And refer to random(7) for a comparison of `/dev/random` and > `/dev/urandom`.
This is Linux. What about other supported POSIX[*] hosts? If any such host has /dev/random that works here, but not /dev/urandom, we regress. *If* there's an actual regression risk: a simple & stupid way to reduce it risk could be falling back to /dev/random when opening /dev/urandom fails. Perhaps only when it fails with ENOENT. Possible implementation: instead of setting a default filename in rng_random_init(), change rng_random_opened() to try /dev/urandom, then /dev/random when filename is still null. Aside: "opened" sounds like a predicate. Goes back to commit a9b7b2ad7b0. > Given the above, change the entropy source for VirtIO-RNG device to > `/dev/urandom`. > > Related discussion in these[1][2] past threads. > > [1] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg08335.html > -- "RNG: Any reason QEMU doesn't default to `/dev/urandom`?" > [2] https://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg02724.html > -- "[RFC] Virtio RNG: Consider changing the default entropy source to > /dev/urandom" > > Signed-off-by: Kashyap Chamarthy <[email protected]> [*] POSIX because common-obj-$(CONFIG_POSIX) += rng-random.o
