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
Conversation
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.
1
1
3
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.
Instead of fixing the real issues, Linus is proposing making a backwards incompatible change to the API that will silently break userspace and open up security vulnerabilities. On top of that, he proposes further overcomplications to what should be a simple and reliable API...
1
3
3
If anything, the security vulnerability in the /dev/urandom API should be fixed and the cargo cult /dev/random and GRND_RANDOM APIs should be deprecated and replaced with a meaningful API to approach VM cloning, an attacker leaking state, etc. by waiting for a full CSPRNG reseed.
1
4
At the moment, all my userspace that needs a CSPRNG (such as establishing ssh connections) blocks until getrandom() returns. It is secure (except for the kernel, which I do not control, doing unseeded PRNG calls) but it can stall for a loooong time. This really isn't good.
1
1
Agreed, the kernel is doing a terrible job at this and the getrandom API being properly designed is making people aware of that which is a good thing. I don't understand why the Linux kernel needs to be so painfully forced into doing things sanely particularly in areas like this.