On Fri, Sep 20, 2019 at 3:44 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Sep 20, 2019 at 1:51 PM Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > > > To be clear, when I say "blocking", I mean "blocks until we're ready, > > but we make sure we're ready in a moderately timely manner". > > .. an I want a pony. > > The problem is that you start from an assumption that we simply can't > seem to do. Eh, fair enough, I wasn't thinking about platforms without fast clocks. I'm very nervous about allowing getrandom(..., 0) to fail with -EAGAIN, though. On a very, very brief search, I didn't find any programs that would incorrectly assume it worked, but I can easily imagine programs crashing, and that might be bad, too. At the end of the day, most user programmers who call getrandom() really did notice that we flubbed the ABI, and either they were too lazy to fall back to /dev/urandom, or they didn't want to for some reason, or they genuinely want the blocking behavior. And people who work with little embedded systems without good clocks that basically can't generate random numbers already know this, and they have little scripts to help out. So I think that just improving the getrandom()-is-blocking-on-x86-and-arm behavior, adding GRND_INSECURE and GRND_SECURE_BLOCKING, and adding the warning if 0 is passed is good enough. I suppose we could also have separate GRND_SECURE_BLOCKING and GRND_SECURE_BLOCK_FOREVER. We could also say that, if you want to block forever, you should poll() on /dev/random (with my patches applied, where this actually does what users would want). --Andy
