Re: [MirageOS-devel] Update on entropy

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA384

Hi,

I do like the proposed changes.  My intuition is that the mirage tool
knows whether nocrypto is used or not (and thus, emits a call to
rng_init before calling main -- it should as well call self_init on
the Random-based RANDOM device, thus the TCP/IP stack doesn't have to
https://github.com/mirage/mirage-tcpip/blob/78124d5eb3095a7cf516d54ca4929ff69a2ce89b/tcp/pcb.ml#L574).
 Based on the same check, the TCP stack could also use the Nocrypto
RANDOM device.

What is crucial here, is that we have a good entropy story on all of
the possible deployment scenarios (and furthermore a way to find out
which entropy sources are mixed in):
- - Xen + ARM: xentropyd (for now), soon cycle counters
- - Xen + X86 (control over dom0): RDSEED/RTDSCP / xentropyd
- - Xen + X86 (ec2): RDSEED/RTDSCP
- - Unix: /dev/urandom

Viewed in a different angle: for each deployment scenario we need a
good story for continuous entropy sources.

The RANDOM device should include a
`entropy_source : entropy_source list`
with
`type entropy_source = [ `RDSEED | `RDRAND | `Xentropyd | `Urandom ]`

Thus, a unikernel could exit early if its favorite (or expected)
entropy source(s) is(are) not present.

Developers should not have to decide which entropy sources to mix in,
but a paranoidic user might want to compile their entropy source
package without rdseed support:  Entropy sources are selected at
runtime from the compiled-in ones (you can manually patch/configure
your entropy source package)!

Which opens the question where to keep the entropy source
implementations and which interface do they need to fulfill?  I
suspect mirage-entropy is a good place to keep them, and do the
runtime detection and mixing logic in there.  Certainly for use cases
without mirage, the direct /dev/urandom feeder should life somewhere
else, maybe in nocrypto.lwt (currently both mirage-entropy-unix and
tls.lwt contain those bits, but certainly I'd like to use Fortuna
without TLS!)?


These changes will also simplify the Tls_mirage interface, which does
not need to be functorized over a ENTROPY device.  (Also, TLS won't be
able to use the abstract RANDOM device because it needs a much richer
API.  I don't think there's much value in extracting this richer API
into mirage-types, which would then need to depend on e.g. Z(arith).)


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

iQIcBAEBCQAGBQJVGsBGAAoJELyJZYjffCjupHUP/0UlyTHcMxNzHo3jQdAEvh1Z
MayhrDomQHmOJMteLLROQ/v3b7tM2xJS2+yiqJIE793aYcfEqWGzxheePW3hwLVV
9OPCzQ19WSYEJg5MRAoEa/Q/umUrEoroDOoGWLj1lpiSkE8Y/N6pXuaE+SisYXjn
8+Gx/HrCj8CL3zp4XWJfA+QRjvX6jKVvmUgeuqaVemdsXYWTn7eTPZ3vCUtm9t0U
SPSB92B5sF+YWA0abSJq4CQzWOlQEuBTVm6I7i8m5UMWYxgiu/9ZkDktUkKhnkao
vD47WpzRasHaKtk2xn1nwE6+BH37zLvJc6wtCqTnu1UB/2FQwk4uuFqlbKeKEKNd
c1CKSuwcAxvIW69rhvyDEwJnudQwy8y8x5560FBWqG6bkBb0wt0qspljDmERB5Vi
oEsupfH8FVl2aLQWI/HCfAc7Jp+O5OFYykAxR3sFUpC4AWle808SsUbACtUEzhzN
gSV8lBoDN11NWxlgOvv2eeqsyJGqzD+koOhVxPqjooejRsGbOTA7Bgu/kA/ZMQE9
uShEN1QK8mJXvEeOzr/4UF+QVq9curfJP969YBxeww5dw4MgV1GhoovcDU5il+7g
FsacQO546tEevk9tOFYBYsGhi7hwYkjzl0sVYuBO5gPvVD2hQkkXMpErYYRCZPlq
3JcAXvo57Nt44aUadHT7
=2E3I
-----END PGP SIGNATURE-----

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