[kata-dev] /dev/urandom or /dev/random

Jon Olson jonolson at google.com
Mon Sep 24 23:40:13 UTC 2018


+tytso at mit.edu -- Ted, I know you had some thoughts on seeding virtio-rng
from /dev/urandom (not sure the listserv will let you post, but it should
catch at least Sebastien and I).

Jon


On Mon, Sep 24, 2018 at 3:21 PM Boeuf, Sebastien <sebastien.boeuf at intel.com>
wrote:

> Hi folks,
>
> Following the discussion from this morning during the Arch committee
> meeting, I have investigated the sporadic issue
> https://github.com/kata-containers/runtime/issues/702 preventing from
> starting some Kata containers.
>
> I have been able to reproduce it pretty easily and I have identified it is
> related to the entropy of the host being almost entirely consumed by the
> first containers, leaving no time for the host to regenerate new entropy
> for the next containers.
>
> 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.
>
> Thanks,
> Sebastien
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20180924/cd0caf63/attachment.html>


More information about the kata-dev mailing list