> On Jun 7, 2019, at 2:11 PM, Dr. Matthias St. Pierre > <matthias.st.pie...@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.