Conversation
/dev/random no longer uses the cargo cult entropy exhaustion nonsense. It works the same way as getrandom(...) and the GRND_RANDOM parameter for getrandom(...) is a no-op. Entire thing is fixed now other than /dev/urandom not blocking until CSPRNG initialization in early boot.
2
Ideally they could be convinced to make /dev/urandom behave the same way as the new /dev/random now that the kernel actively fixes the issue of indefinite blocking itself. They probably won't because in theory that might not work in some super weird / broken environment.
1
Most modern devices have an SoC CSPRNG and entropy passed from the bootloader, neither of which the kernel actually credits for providing entropy. Both of those are enough to properly seed it in practice though. Also, kernel finally learned how to seed itself via non-CPU HW RNGs.
1
Android has userspace code to read /dev/hw_random into /dev/random in early boot and then on a regular basis in addition to saving / restoring entropy via persistent state. The kernel *finally* learned how to do that itself when it brings up the HW RNG. Think it's just at init.
1
IMO, the kernel should use pstore to save / restore entropy for itself in very early boot. I've suggested that on multiple occasions. Hasn't gone anywhere though. I personally don't really care since the problem is solved 10x over in different ways for modern smartphones anyway.
1
1
Snapdragon has a hardware CSPRNG and entropy is passed to the kernel from the bootloader via their EDK2-based bootloader. Kernel entropy generation has a lot to work with (UFS SSD and other things) and then userspace has saving/restoring entropy + reads from hw rng repeatedly.
1
Secure elements also each have their own hardware CSPRNG. Pixels have 2 of those: Qualcomm SPU and the Titan M. I'm not sure if either is actually used to seed the kernel CSPRNG. It doesn't really matter. It's all overkill at this point. Much more important things to be improved.