Hey Linus, One thing I should clarify is that the GRND_INSECURE stuff for getrandom(2) is a bit of a red herring with regards to the primary intent of this patch, which is making /dev/urandom, the old char device, block waiting for entropy. Right now, we have: /dev/random = getrandom(0) /dev/urandom = getrandom(GRND_INSECURE) This proposal is to make that: /dev/random = getrandom(0) /dev/urandom = getrandom(0) Along the way I also got rid of GRND_INSECURE, but arguably that should be a separate patch. This here is mostly about making /dev/urandom block. On 2/11/22, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
When try_to_generate_entropy() doesn't work, I think you now removed the possible fallback for user space to say "yeah, just give me best effort". And you might re-introduce a deadlock as a result. Those systems are arguably broken from a randomness standpoint - what the h*ll are you supposed to do if there's nothing generating entropy - but broken or not, I suspect they still exists. Those horrendous MIPS things were quite common in embedded networking (routers, access points - places that *should* care) Do I have a constructive suggestion for those broken platforms? No, I don't. That arguably is the reason for GRND_INSECURE existing, and the reason to keep it around.
It sounds like you're proposing a middle way here, which would be to just call try_to_generate_entropy() (the "Linus Jitter Dance" code) if !crng_ready() in /dev/urandom and getrandom(GRND_INSECURE). That's actually a pretty good idea. It wouldn't break anything and would only make the situation better on most systems. I think I'll probably take your suggestion there, as it seems uncontroversially to be an improvement. Revisiting the original proposal though:
I'd be willing to apply such a thing anyway - at some point "worry about broken platforms" ends up being too weak an excuse not to just apply it - but I'd like to hear more of a reason for this
simplification. The justification for always waiting for randomness and never returning insecure randomness to userspace isn't so much about simplifying the code -- this patch isn't very large anyway -- but rather for simplifying userspace crypto footguns. After several decades of endless user confusion, we'd finally be able to say, "use any single one of our random interfaces and you'll be fine. They're all the same. It doesn't matter." And that, I think, would really be something. Finally all of those blog posts and disagreeing forums and contradictory articles would all become right about whatever they recommended. So the one side of this is, "misconfigured userspace in a computer history museum might run into trouble." The other side is, "everybody gets good random numbers always." Today's thread's new addition to that old argument is that your jitter dance makes the downside a heck of a lot less than it used to be. What do you make of that line of thought? Jason
