Hi Andy, On Fri, Sep 20, 2019 at 10:52:30AM -0700, Andy Lutomirski wrote: > 2. Fix what is arguably a straight up kernel bug, not even an ABI > issue: when a user program is blocking in getrandom(..., 0), the > kernel happily sits there doing absolutely nothing and deadlocks the > system as a result. This IMO isn't an ABI issue -- it's an > implementation problem. How about we make getrandom() (probably > actually wait_for_random_bytes()) do something useful to try to seed > the RNG if the system is otherwise not doing IO.
I thought about it as well with my old MSDOS reflexes, but here I doubt we can do a lot. It seems fishy to me to start to fiddle with various drivers from within a getrandom() syscall, we could sometimes even end up waiting even longer because one device is already locked, and when we have access there there's not much we can do without risking to cause some harm. On desktop systems you have a bit more choice than on headless systems (blink keyboard leds and time the interrupts, run some disk accesses when there's still a disk, get a copy of the last buffer of the audio input and/or output, turn on the microphone and/or webcam, and collect some data). Many of them cannot always be used. We could do some more portable stuff like scan and hash the totality of the RAM. But that's all quite bad and unreliable and at this point it's better to tell userland "here's what I could get for you, if you want better, do it yourself" and the userland can then ask the user "dear user, I really need valid entropy this time to generate your GPG key, please type frantically on this keyboard". And it will be more reliable this way in my opinion. My analysis of the problem precisely lies in the fact that we've always considered that the kernel had to provide randoms for any use case and had to cover the most difficult cases and imposed their constraints on simplest ones. Better let the application decide. Willy
