[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Mon, Nov 24, 2014 at 10:09 AM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
On 24 Nov 2014, at 09:55, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
> 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)

I've now got a prototype of this. There's now a daemon called "xentropyd" which watches for domains being created and connects to them, offering them entropy. The entropy is read from /dev/urandom through a rate-limiter and sent to the domain over a secondary console ring.

To give it a go try:

opam remote add mirage-dev-dave git://github.com/djs55/mirage-dev#xentropyd
# install the depexts, mainly the xenctrl.h header:
# apt-get install `opam install xentropyd -e ubuntu`
opam install xentropyd

You can then runÂ~/.opam/system/bin/xentropyd as root in domain 0. It'll print debug to stdout by default.

cd mirage-skeleton/entropy
mirage configure --xen
mirage build

This example simply prints a chunk of received entropy to the console.

The main outstanding question is what should the default mirage-entropy-xen behaviour be? I've created an RFC-style patch which shows how to use the new entropy source:

It's intended more for discussion than merging since it creates a hard dependency on xentropyd.


> 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.


> 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


MirageOS-devel mailing list

Dave Scott
MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.