> On the BSDs getentropy() is hence unconditionally blocking
lore.kernel.org/linux-ext4/201
Lennart/Linux people still don't get it.. OpenBSD getentropy(2) does not block by design. The same as /dev/urandom.
man.openbsd.org/random.4
man.openbsd.org/getentropy.2
Conversation
Replying to
There are lots of things Lennart doesn't get. Please don't mistake him as representative of all the Linux people. 😐
3
1
4
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.
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
Show replies