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

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

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

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


I'm happy about the discussion here on the list, and appreciate any
comments and feedback (especially PRs ;) or ideas for other sources of
entropy in a virtualised environment),

Hannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCQAGBQJUcwB3AAoJELyJZYjffCjuJ2cP+wU9fEN3w8NRZUJucFEkTV9l
eItbJrtqyW2bCLHu0MwxvkbAoFJ1SXNIrw4K1b/smwNtQaONOCrH+ZPeVYha+Jtb
cca6JV3J5JbjJ+ioCw2vSvS4exCzdURL6kRM3ja0Qg+3ea1zQC3HjFCLpUuAO7mz
NbpFbdGAyZqVb9OECBJ3u52puOcZC6nRV5QlbgtLYZycufnEALfYkytuGddMrSHn
XknxY1W2Pb369A5+8rc/ZldPptwlfY6OHDPIlm+lB4gHnD3JMZUuZvmZmRp7SIvI
tab7Hg5SovkYcXsRB6WbPnBQhtJBZ5+uBH3CNAQ4bLLYQjZg7THyFSCHKi/DV4HG
/OuZc4gQ7Fh79rLHc89tpndNRX2sX2FQAPNFEIF6EoqSrQ/PvSWPAG59fYKnijho
HgwEYkjFvUmyQiPSa8WmMAd5PCDrTOaSGpo8IajZDfmEVWBFdtzKxQUzgMK77vsW
aHb6Vy1jDiygdmZAmc2c54Sjc0HAtkHo9Vn6s1MJXrwDVo6yPG7YA6JVsqo0LpMJ
p5Q9axLlRVmUgMjsiXeCLu3hc9pvq6j+G+0dLZIfzwzYjERp8ugIMi028SCwhXMk
r3liFc7ThwKvvCuUPDNXBBWj5HhXfbpM+/RgUMKDMzERAA2e8HuFkW4kM5YvZnvU
MW6Zddvx7bZ2Gjvn0VYu
=1SiK
-----END PGP SIGNATURE-----

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