[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916690
> 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.


Reply to: