I'd prefer to keep it working with the warning, as I am working on getting the end-to-end TLS stack in shape in mirage/mirage#247

Instead of disabling it, how about an attempt to use RDRAND to seed it rather than time? That would at least let it work without the front/backend Rng drivers being necessary.

See #7 and mirage/mirage#323 for a short-term workaround.

In many ways, #7 might be even worse.

It makes every sequence of "highly unpredictable" behaviors of a unikernel exactly the same on every boot.

With randomness completely dependent on time of the day when the kernel was booted (well, when Random.self_init was called), if an adversary can observe or cause booting, it is fairly easy to guess the exact RNG state and predict further outputs.

With randomness that is identical on every run, the mere fact that a kernel rebooted is sufficient. There is a wealth of cryptographic operations with horrible failure modes in this scenario.

For a simple example, DSA signing is often done with a random parameter provided to the signing process. If an adversary can observe two signatures generated with the same random parameter, they can easily recover the secret key. With fixed "entropy", the only real entropy in this process is ordering of requests to the unikernel. To fully compromise the long-term secret, it is enough to succeed twice in being the first one after boot to request a signature.

Note that nocrypto does not do that by default; the random parameter in question is derived from other parameters of the signing request, because @hannesm wisely pushed for rfc6979, but the case of traditional DSA is illustrative of a common hard requirement of cryptographic schemes and ensuing catastrophic failure: that one-time values do not repeat. Another example off the top of my head is GCM, which also breaks down in an instant if a nonce is reused.

From a security standpoint, this is barely stronger than having the sequence 1, 2, 3, ... stand in for randoms on every run. It doesn't do much more than deceive the user into thinking there is some data protection going on, when the protection is actually easy to subvert and highly dangerous to rely on for any confidential data.

@hannesm and I were already suggested this scheme during the summer and we both disliked the idea.

Agreed. I am closing #7.

just to be on the same page @pqwy: Random.self_init https://github.com/ocaml/ocaml/blob/638a953bcf61678307fa5d0e1a969aaaf3f1ab20/byterun/sys.c#L364 tries to open /dev/urandom (doesn't exist on mirage), calls gettimeofday / time / getpid / getppid
gettimeofday is implemented by minios - on x86 there's some wallclock from dom0, on arm it starts with 0: https://github.com/talex5/xen/blob/devel/extras/mini-os/arch/arm/time.c#L54
I doubt there's much non-determinism in arm mirage startup -- I believe Random is seeded very deterministically there... (that's why this PR here exists!)

now that we have xentropyd, closing this...