Re: Handling of entropy during boot
Hi,
This thread seems to have gone quite for some time. Re-Reading the
thread I don't see any solutions being proposed that will truly suit
everyone.
If I have correctly understood the problem we are seeing a change from a
more open and trusting software environment to one with more emphasis on
security that is also less trusting:
* More packages are requiring the use of the kernel's high quality
entropy pool (including aspects of the kernel itself)
* At the same time questions are being asked over how much we can trust
our entropy sources. There is no agreement of which sources we should
trust; this appears to be based upon a cultural perspective rather than
evidence based.
* Different platforms may have different entropy sources available to
them (think desktops, mobile devices, headless servers, small IoT
devices & virtualised instances)
What does this mean for Buster?
Some services may take a long time to start. I am not talking about a
few seconds here, but instead minutes or even hours. I myself see sshd
timing out and being restarted by systemd several times before finally
starting some 7 min after the rest of the system on my ARM64 Mustang
platform. I have seen reports of taking literally several hours for all
services to start on some NAS boxes.
Unfortunately some services fail to start completely, others are
terminated and unlimited restart attempts are made.
In all cases, that I have seen, there is no mention of the reason for
the failed start being that there is insufficient entropy available.
This itself is a bug whatever your view on how to address lack of
available entropy during start-up.
We should at the very least state the reason a service has not started.
I believe that systemd has the ability to only start services when a
given event has happened (i.e. wait for network). Should we be asking
for wait for “entropy pool > x bytes” before starting a given service?
Should we add to or change the possible entropy sources?
Increasing the number of different sources of entropy may well reduce
the time waiting for sufficient entropy, (although this is not an excuse
not to explain why a service has failed to start).
There has been some discussion about adding in further possible entropy
sources, and whether or not that source is enabled by default of not.
In general nobody appears to be arguing against having the ability to
use additional entropy sources, the only debate is over which should be
enabled by default within debian.
This debate appears to boil down to ‘do I trust this source’ and it is
accepted that this is very much dependant upon what the installation is
going to be used for AND your geo-political leanings. i.e. you may well
trust a HRNG for an Intel device if you are an American, but be less
inclined to trust one from China, and vice versa.
I don't think that we can OR SHOULD make a sensible decision for an out
of the box experience that will suitable for all users.
Perhaps instead we should consider a tool (to be included in DI as well
as just the archive) that can present the different options and allow
the user to decide?
If this is the way we as a project decide to go I would very much like
to be involved in this new package. Such a tool is probably beyond my
ability to write, however I would be very happy to work on the design,
UI and testing.
Is this the right approach to take?
Best regards
Andy
Reply to: