Re: [MirageOS-devel] mirage-entropy design proposal

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 24 Nov 2014, at 09:55, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA384
> 
> Hi,
> 
> let me try to summarise the entropy sources:
> a) configuration-time compiled-in random (patch from nic)
> b) gettimeofday seeded (OCaml) Random (current code in mirage-entropy-xen)
> 
> c) adapt Lwt engine loop to feed some bits of entropy (david
> suggested, PR to lwt)
> d) xenstore/vchan continuously feeding entropy from dom0 (dave is
> working on that)
> e) rdrand (code https://github.com/TimKnast/ocaml-rdseed)

Following on from a), we could also dump random data in a block device
at image build-tiem, and delete it whenever it's read.

> 
> Let me remark that a and b can only be used for initial seeding (there
> isn't any more entropy to get from these later)! Also, using only one
> entropy source alone is not a good idea.

Absolutely.

> 
> Now some real-world cases (only Xen-based, in unix land it's simple
> (rely on host /dev/(u)random)!):
> 1) ARM (cubieboard, full control over dom0 [no time]): a, c, d
> 2) X86 (server hosting, full control over dom0): a, b, c, d, e?
> 3) X86 (cloud hosting, no control over dom0): a, b, c, e?
> 
> I still think 3 is a bit weak (esp if rdrand is not available) -- the
> solution I can think of right now is to come up with a deployment
> service, which receives unikernels and has API keys to deploy the
> image(s). This service has to be hosted on a machine with real
> entropy, and dumps some of its entropy into the image. It has to
> ensure that every image is deployed only once (or: each image to be
> deployed is first modified to contain some fresh random data). This
> would give us sth similar to /var/db/entropy/ (where the seed is saved
> during shutdown, fed into the RNG during startup).

Related to above, except the first revision doesn't need machine<->machine
comms

Anil

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel