Re: Handling of entropy during boot
- Date: Thu, 10 Jan 2019 17:37:39 +0100 (CET)
- From: Stefan Fritsch <sf@xxxxxxxxxxx>
- Subject: Re: Handling of entropy during boot
On Thu, 10 Jan 2019, Michael Biebl wrote:
> Am 10.01.19 um 15:51 schrieb Stefan Fritsch:
> > On Thu, 10 Jan 2019, Michael Biebl wrote:
> >>> ACK, we also had to do the same in Grml[.org] and our latest release
> >>> (2018.12). Now we automatically enable haveged when users boot using
> >>> the ssh boot option (which is something Grml specific, taking care
> >>> of setting user password and invoking the ssh service).
> >> And this is a perfect example why crediting the seed file (#914297) is
> >> not a solution to this problem.
> > While I still think this case should be handled by documentation, let's
> > try to find a way forward that we can agree upon.
> > I think the absolute minimum we need something that prints a big fat
> > warning during boot if the RNG is not yet initialized, points out that
> > further services may block and that the admin should add entropy sources
> > like virtio-rng or rdrand. The time when this warning should be printed
> > should probably be before network is started, because if the admin has
> > configured vpn services in /etc/network/interfaces, those will already
> > block because of lack of entropy.
> > A second thing we need is a service that finishes when the RNG is
> > initialized and that has a suitable large timeout for starting (maybe one
> > day?). Services that need randomness can then depend on that service and
> > don't need to set their own timeout to huge values. Also it is a lot
> > easier to see what's wrong if the "wait for RNG" service is blocking than
> > if some random network service is blocking.
> > More things should be done but maybe we can figure those out while we
> > implement the above two things. Can we agree on this?
> I'd prefer having this documented in the release notes:
> with possible solutions like installing haveged, configuring virtio-rng,
> etc. depending on the situation.
That would be an extremely user-unfriendly "solution" and would lead to
countless hours of debugging and useless bug reports.