On Tue, Sep 25, 2018 at 09:11:59AM +0100, Dr. David Alan Gilbert wrote:
* Boeuf, Sebastien (sebastien.boeuf@intel.com) wrote:
[U]Randomly chiming in. [...]
Currently, the virtio-rng device exposed by Qemu relies on /dev/random on the host, and because this device will block any access to it until some more entropy is ready, that's why we end up getting the timeout from the gRPC client as the agent is not ready, hence the gRPC server does not run yet (the guest is blocked on getting new entropy from /dev/random). One way to workaround this issue is to tweak the parameters of the virtio-rng device such as max-bytes=10, limiting the amount of entropy that can be consumed by the guest each period. This means that starting one container will not consume all host's entropy, but eventually, if we run a lot of containers, we'll be very likely to hit this same issue.
The long term solution seems to rely on /dev/urandom device as this one will not block if no entropy is ready yet. But from what we can read online, it seems that some people have some security concerns about it. I'd like to understand if those worries are valid or not, and if we should keep thinking about another way to fix this issue.
I'm just curious what are those concerns. Because the official documentation[1] of random(4) says: 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. And that of urandom(4) says[2]: Usage 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 As you noticed, QEMU still defaults the source of entropy for Virtio-RNG device to `/dev/random`. I don't see a reason why the default source for Virtio-RNG shouldn't be changed to `/dev/urandom`. FWIW, to that end, there are two related threads[3][4] on 'qemu-devel'. (No resolution yet, though.) [1] http://man7.org/linux/man-pages/man4/random.4.html [2] http://man7.org/linux/man-pages/man4/urandom.4.html [3] https://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg02724.html -- [RFC] Virtio RNG: Consider changing the default entropy source to /dev/urandom? [4] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg07052.html -- Any reason QEMU doesn't default to `/dev/urandom`?
Those concerns seem mostly to be in older discussions.
That's also my observation, FWIW.
On the BSDs you find that they're actually the same device linked together (behaving as I understand it in a way that's similar to Linux's urandom).
Since you really never want your VMs blocking, I'd suggest just telling qemu to use urandom; you can pass it as a parameter to -object rng-random
-- /kashyap