VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

[Viktor Dukhovni]

> On Jun 7, 2019, at 2:11 PM, Dr. Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com> wrote:
> 
>> The init system would
>> need to create this kind of service, and then all software not using
>> getentropy()/getrandom() would need to depend on that service. It
> 
> FWIW: systemd already has a service for saving and restoring a random seed.
> If I understood Tomas correctly, the saved seed is added to the random pool,
> but without crediting any entropy to it (which sounds reasonable to me).

That's a different issue.  What I was suggesting was a service that
waits for seeding to be ready.  So that other services can depend
on that service, with that service using various sources to adequately
seed the kernel RNG, with configurable additional sources beyond the
save file, possibly with a non-zero entropy estimate.  Thus, for example,
a virtual machine or container might make use of an interface to get a
a trusted seed from the host hypervisor/OS.  Or a physical host might
trust its TPM, ...

This is not the sort of thing to bolt into the kernel, but is not
unreasonable for systemd and the like.

Applications can then use getentropy() and not even block at boot
time, if the system collects entropy at boot automatically and
without excessive delay.  The job of improving the source quality
and eliminating avoidable delay is then (correctly IMHO) the
responsibility of the platform's init system.

As for what to do on older platforms, ... add an entropy gathering
service to the system start up configuration, and make applications
that need early seed material depend on that service.

Perhaps the OpenSSL project can curate some examples of such service
configurations/scripts.  The simplest might be just DEVRANDOM_WAIT
as a service that runs at boot, and only reports "ready" once
/dev/random is ready.  After that applications can just use
/dev/urandom with some confidence of adequate seeding.

-- 
	Viktor.