New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

systemd-random-seed should credit the entropy #4271

Open
patrakov opened this Issue Oct 2, 2016 · 9 comments

Comments

5 participants
@patrakov
Copy link

patrakov commented Oct 2, 2016

Submission type

  • Bug report
  • Request for enhancement (RFE)

NOTE: Do not submit anything other than bug reports or RFEs via the issue tracker!

systemd version the issue has been seen with

231

NOTE: Do not submit bug reports about anything but the two most recently released systemd versions upstream!

Used distribution

Debian Stretch

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.

@patrakov patrakov changed the title systemd-rannom-seed should credit the entropy systemd-random-seed should credit the entropy Oct 2, 2016

@poettering

This comment has been minimized.

Copy link
Member

poettering commented Oct 4, 2016

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.

@patrakov

This comment has been minimized.

Copy link

patrakov commented Oct 4, 2016

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.

@mbiebl

This comment has been minimized.

Copy link
Contributor

mbiebl commented Oct 4, 2016

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

@martinpitt

This comment has been minimized.

Copy link
Contributor

martinpitt commented Oct 19, 2016

There is a GnuTLS PR which appears to address this: https://gitlab.com/gnutls/gnutls/merge_requests/111/

@poettering

This comment has been minimized.

Copy link
Member

poettering commented Nov 23, 2016

There's a PR btw, in #4513.

@mbiebl

This comment has been minimized.

Copy link
Contributor

mbiebl commented Nov 24, 2016

@martinpitt This fix has been included in GnuTLS 3.5.6 which landed in Debian unstable 2 weeks ago. It seems to have fixed the issue with NetworkManager

@patrakov

This comment has been minimized.

Copy link

patrakov commented Nov 25, 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.

@kroeckx

This comment has been minimized.

Copy link

kroeckx commented Oct 30, 2018

Can you point at any imaging tool that ships a seed file? I really consider it to be a serious bug in the imaging tools if the seed file is part of the image.

@poettering

This comment has been minimized.

Copy link
Member

poettering commented Oct 31, 2018

@kroeckx well, people script their own stuff with debootstrap and dnf --installroot=, and it's unlikely many folks who do that even know about the seed file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment