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

Venegas Munoz, Jose Carlos jose.carlos.venegas.munoz at intel.com
Tue Sep 25 22:32:52 UTC 2018


Thanks for the feedback! 

-----Original Message-----
From: Boeuf, Sebastien [mailto:sebastien.boeuf at intel.com] 
Sent: Tuesday, September 25, 2018 5:26 PM
To: Theodore Y. Ts'o <tytso at mit.edu>; Jon Olson <jonolson at google.com>
Cc: kata-dev at lists.katacontainers.io
Subject: Re: [kata-dev] /dev/urandom or /dev/random

Thanks for the feedback Ted.

I am glad I've asked as it feels safer to go with /dev/urandom solution now :)

Thanks,
Sebastien
________________________________________
From: Theodore Y. Ts'o [tytso at mit.edu]
Sent: Tuesday, September 25, 2018 3:15 PM
To: Jon Olson
Cc: Boeuf, Sebastien; kata-dev at lists.katacontainers.io
Subject: Re: [kata-dev] /dev/urandom or /dev/random

On Mon, Sep 24, 2018 at 04:40:13PM -0700, Jon Olson wrote:
> +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).

My recommendation is to just seed virtio-rng from /dev/urandom.
Here's why.  /dev/urandom provides a cryptographic random number generator, and assuming it is adequately initialized, that should be
*fine* for pretty much all practical purposes.  And on the sort of systems you would be using as a Host, there are enough hardware devices that /dev/urandom will be initialized very quickly --- in practice, well before any VM's will be started.

Furthermore, all modern x86 systems have RDRAND by now, and on those systems, the host kernel will mix RDRAND output with CRNG before sending the random numbers out via getrandom(2) or /dev/urandom.

From a guest perspective, you have to trust the Host system anyway.
The host as the ability to read or modify arbitrary guest memory, including that used by the kernel.  The host can mess with the guest kernel before it's booted, or change the contents of the emulated hard drive.  So trusting that the host CPU has implemented RDRAND correctly isn't a stretch.  So even if the customer running the VM is a tin-foil-hatter who believes the NSA may have backdoored RDRAND and not have it be discovered or leaked out, in most cases, they aren't the sort of people who would want to use a cloud infrastructure.
They're much more likely to want to use hardware which always stays under their personal control.

And even if you *do* believe the NSA has somehow managed to sneak a backdoor into Intel CPU designs without it become public, that still means that you have to break the CRNG.  And practically speaking, assuming it's been initialized correctly, if you can break the CRNG, we've got much bigger problems, since that implies you can't trust the basic crypto primitives we use to secure our entire internet.

Cheers,

                                                - Ted

_______________________________________________
kata-dev mailing list
kata-dev at lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev


More information about the kata-dev mailing list