See https://news.ycombinator.com/item?id=6550256 for a much longer argument about it.
I don't necessarily agree with his justification, but that's also a difference in technical opinion. The only way I'd fault him is if I can come up with a an approach that addresses his concerns yet he still refuses to accept them.
Full disclosure: I've actually interacted with him on a few occasions. IMO calling him risk/change-averse would be an understatement, which partly explains this stance. While at times frustrating for us, this is exactly the quality you want in someone maintaining such a critical part of the kernel.
Edit: Thanks for the link!
If it's still not blocking, it seems that still the best thing to do is using getrandom( ..., 0 )?
You need separate hardware to safely prevent these 128bits from leaking.. but then why don't we ditch whole idea and implement true HW RNG instead?
His point is that the mechanism used to generate random bytes by a modern CSPRNG is virtually identical to the mechanism that encrypts the application_data in a TLS session.
Mechanism can be identical, but the stakes are definitely not.
So those bits will be known to software, no matter where the generation happens.
Your argument would make a bit of sense if you were arguing for doing all cryptographic operations in hardware. Like on a smartcard. But that's not what we're talking about.
I find /dev/random frustratingly confusing.
This suggests that you're not an expert. Therefore, it is wise to just stick to what the experts write, in articles such as this. That's what I do. Cryptography is a very complex subject; non-experts who give advice without knowing exactly why they are saying what they're saying are contributing to the problem, so please avoid doing that.
I used to be very confused, too, and after learning something about it, I wrote that page. Almost didn‘t finish and publish it when tptacek put his page up, but by that time I had already invested most of the effort, and I wanted to be less terse.
Edit: actually, I think I would recommend everyone interested in this subject to read at least a few texts by actual experts (professors in cryptography and people who work for high-stakes security businesses), to get a taste of what it's all about.
If it’s unnecessary to ever prefer /dev/random to urandom, then why does /dev/random’s current blocking implementation still exist? Surely between all of the kernel developers, between all of the Unix-ish OS’s, over the last couple of decades would have realized that /dev/random should simply act like /dev/urandom?