If by "he" you mean Linus, then that's correct.
Lennart is actually willing to fix systemd.
Conversation
I meant Lennart. My (perhaps mis-) understanding of the situation was that this whole problem arose because systemd insisted on using getrandom for non-cryptographic purposes at early boot, deadlocking the system before entropy pool was initialized.
1
That's how it started, but it has been Linus insisting on making getrandom insecure by default, with some extremely bad takes on crypto: lore.kernel.org/linux-ext4/CAH
lore.kernel.org/linux-ext4/CAH
lore.kernel.org/linux-ext4/CAH
Lennart has been saying don't do that:
lore.kernel.org/linux-ext4/201
1
2
Yes, I'm aware that Linus is and has always been badly wrong about crypto/entropy. "Don't do that" is helpful. Does Lennart have a plan for fixing systemd and getting Linus to do the right thing here?
1
2
Based on what I understand, what Lennart needs to do is say "systemd was wrong to use getrandom here and I'll fix it. Don't break getrandom and everything depending on it for cryptographic safety to work around my systemd bug."
1
2
The Linux kernel needs a strong CSPRNG in early boot. It doesn't have a real excuse for this being broken. There should be no issue with every program on the system using getrandom from early boot especially since the Linux kernel had important uses for the CSPRNG before PID 1.
1
1
6
For example, the Linux kernel has to use the CSPRNG for kernel and userspace ASLR bases, kernel and userspace SSP, memory tagging and other probabilistic mitigations. There are also many important and real use cases for generating keys and making secure network connections early.
1
1
2
Even if the persistent keys have already been previously generated, it's necessary to have a proper CSPRNG to create secure connections with those keys, due to how protocols are implemented with forward secrecy. A weak CSPRNG will compromise connections even with existing keys.
1
2
3
The baseline should be provided by a few things: regularly saving entropy and restoring that in early boot, passing gathered entropy from each boot stage to the following boot stage and obtaining it from hardware CSPRNG support. Kernel can also generate more than enough itself.
1
1
3
There are existing protocols for passing entropy to the kernel from the previous boot stage via the EFI RNG protocol or the device tree. Unfortunately, until recently, the Linux kernel made poor use of this. Using bootloaders like GRUB between UEFI and the kernel also breaks it.
Similarly, many devices provide support for low-level persistent storage which the kernel knows how to use for saving crash information on panic for later retrieval: lwn.net/Articles/43482 freedesktop.org/software/syste. The Linux kernel could be using this to save / restore entropy.
1
1
1
It could also be doing a much better job at generating entropy itself. There's no good excuse for it simply blocking indefinitely and waiting for something else to generate entropy, which doesn't happen because the boot process is blocked. It can do work in that blocking call.
2
1
5
Show replies