Open Stack

On Tue, Sep 25, 2018 at 09:11:59AM +0100, Dr. David Alan Gilbert wrote:
> * Boeuf, Sebastien (sebastien.boeuf at 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