SoylentNews is people
SoylentNews
Recent upgrades that depend on the new Linux getrandom() syscall can cause OpenSSH to delay starting for tens of minutes while waiting for enough bytes of randomness. There are currently not any feasible work-arounds.
Systemd makes this behaviour worse, see issue #4271, #4513 and #10621.
Basically as of now the entropy file saved as /var/lib/systemd/random-seed will not - drumroll - add entropy to the random pool when played back during boot. Actually it will. It will just not be accounted for. So Linux doesn't know. And continues blocking getrandom(). This is obviously different from SysVinit times when /var/lib/urandom/random-seed (that you still have laying around on updated systems) made sure the system carried enough entropy over reboot to continue working right after enough of the system was booted.#4167 is a re-opened discussion about systemd eating randomness early at boot (hashmaps in PID 0...). Some Debian folks participate in the recent discussion and it is worth reading if you want to learn about the mess that booting a Linux system has become.
While we're talking systemd ... #10676 also means systems will use RDRAND in the future despite Ted Ts'o's warning on RDRAND [Archive.org mirror and mirrored locally as 130905_Ted_Tso_on_RDRAND.pdf, 205kB as Google+ will be discontinued in April 2019].
Related post: OneRNG: a Fully-Open Entropy Generator (2014)
(Score: 3, Insightful) by sjames on Saturday December 22 2018, @08:22AM (6 children)
Care to name one?
On the other hand, systemd will be rightly blamed when an embedded system appears to fail on upgrade with systemd taking over an hour in some cases to get past the random-seed issue.
In all cases like these, the rule in Unix is that the system should implement mechanism and leave policy to the admin.
(Score: 0) by Anonymous Coward on Saturday December 22 2018, @12:16PM
If you're running SystemD in an embedded system you'd probably be better off with XP.
(Score: 2) by loonycyborg on Saturday December 22 2018, @03:28PM (4 children)
Yes, it's easy to spot boot delay, research the issue and ensure there is some good source of entropy such as TPM or RDRAND. And all before the embedded system gets into user's hand.
(Score: 2) by sjames on Saturday December 22 2018, @05:57PM (2 children)
What makes you think either of those exist on an embedded device?
Some have it, some don't.
It's also easy to make it configurable and let the admin decide policy, but systemd is not very good about following the rule.
(Score: 2) by loonycyborg on Sunday December 23 2018, @09:40AM (1 child)
What do you mean? They agreed to make it configurable. The argument is only about the default value of that setting :P
(Score: 4, Informative) by sjames on Sunday December 23 2018, @06:17PM
They have agreed to nothing, that item is still open. The current discussion is more like reluctant and grudging potential agreement but let's hide that option somewhere and consider it to be experts only/debugging.
On the matter of systemd consuming the limited entropy available at boot time, they have agreed that it isn't really necessary but that they're going to keep doing it anyway.
The rest is workarounds with the kernel or the initrd taking over and doing things behind systemd's back so necessary things can get done without dealing with systemd's inability to handle it the one true systemd way.
(Score: 1) by DeVilla on Saturday December 22 2018, @08:22PM
Someone didn't read Ted's warning about RDRAND or doesn't care.