There are lots of things Lennart doesn't get. Please don't mistake him as representative of all the Linux people. 😐
Conversation
Never thought I'd be defending him, but in this case, Lennart is mostly right - about the crypto, and about about how Linus is wrong.
1
I thought he was insisting on the broken-crypto getrandom that would return unsafe results, so systemd would boot. Is this incorrect?
1
1
If by "he" you mean Linus, then that's correct.
Lennart is actually willing to fix systemd.
1
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.
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
Show replies