On Sun, Sep 15, 2019 at 12:08:31PM -0700, Linus Torvalds wrote: > My suggested patch left the /dev/random blocking behavior, because > hopefully people *know* about the problems there. > > And hopefully people understand that getrandom(GRND_RANDOM) has all > the same issues. I think this one doesn't cause any issue to users. It's the only one that should be used for long-lived crypto keys in my opinion. > If you want that behavior, you can still use GRND_RANDOM or > /dev/random, but they are simply not acceptable for boot-time > schenarios. Oh no I definitely don't want this behavior at all for urandom, what I'm saying is that as long as getrandom() will have a lower quality of service than /dev/urandom for non-important randoms, there will be compelling reasons to avoid it. And I think that your bounded wait could actually reconciliate both ends of the users spectrum, those who want excellent randoms to run tetris and those who don't care to always play the same party on every boot because they just want to play. And by making /dev/urandom behave like getrandom() we could actually tell users "both are now exactly the same, you have no valid reason anymore not to use the new API". And it forces us to remain very reasonable in getrandom() so that we don't break old applications that relied on urandom to be fast. Willy
