Xen project Mailing List

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:
>
> -----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)

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.

git clone git://github.com/mirage/mirage-skeleton

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:

https://github.com/mirage/mirage-entropy/pull/8

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

Cheers,

Dave

> 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

Dave Scott

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