Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
systemd-random-seed should credit the entropy #4271
NOTE: Do not submit anything other than bug reports or RFEs via the issue tracker!
systemd version the issue has been seen with
NOTE: Do not submit bug reports about anything but the two most recently released systemd versions upstream!
In case of bug report: Expected behaviour you didn't see
System should boot quickly
In case of bug report: Unexpected behaviour you saw
NetworkManager cannot start for 1 min 30 sec.
In case of bug report: Steps to reproduce the problem
Install Debian Testing into qemu. Make sure that network is managed with NetworkManager (it is sufficient to select the default GNOME desktop environment during installation). Boot, and reboot again, and see how 90 seconds of systemd's patience on NetworkManager run out.
This has been traced in https://bugs.debian.org/837597 to the fact that NetworkManager calls getrandom(), but the non-blocking random pool is not initialized yet. I.e. not enough entropy, even though systemd-rannom-seed has completed successfully.
See also https://lwn.net/Articles/694434/ for some insight - namely, the result is that just writing to /dev/urandom does not credit any entropy to the system (even though there is, in fact, entropy - carried over from the previous boot), and that an ioctl (RNDADDENTROPY) is necessary for the kernel to take the new entropy into account.
Hmm, so do we really have enough reason to credit the entropy here? I mean do we really know that the randomness we stored on the previous boot has a high enough entropy?
I am particularly concerned with systems that use "golden master" images, that contain the a random seed and are duplicated many times. In this case i figure the entropy of the random seed should be considered zero, but I doubt we could ever distinguish this case from the normal, clean case.
I'd really prefere if there could be a broader discussion around this before we make a change to this, because quite frankly I don't oversee all the implications of this.
I understand your concern - it is 100% valid. And there indeed should be a discussion. The real bug here is that there is no well-defined point in the boot sequence where it is guaranteed that there is enough entropy so that the non-blocking random pool, when used by getrandom(), actually doesn't block.
It might help if we look what OpenBSD people do here (I honestly don't know and won't have a chance to look until tomorrow). They also save/restore their random seed across reboots, and they had getrandom() for much more time than it is in Linux.
Somewhat related to this is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760029 where we were asked to run "/lib/systemd/systemd-random-seed save" as part of the package installation process.
@martinpitt raised his concerns in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760029#42
There is a GnuTLS PR which appears to address this: https://gitlab.com/gnutls/gnutls/merge_requests/111/
referenced this issue
Oct 31, 2016
I understand that the trigger for this bug report has been resolved. However, the real concern ("there is no well-defined point in the boot sequence where it is guaranteed that there is enough entropy") is IMHO still valid, still needs investigation of the prior art in OpenBSD (I promise to do it before January 1st), and further discussion after that.