On Fri, Sep 20, 2019 at 11:07 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * Linus Torvalds: > > > Violently agreed. And that's kind of what the GRND_EXPLICIT is really > > aiming for. > > > > However, it's worth noting that nobody should ever use GRND_EXPLICIT > > directly. That's just the name for the bit. The actual users would use > > GRND_INSECURE or GRND_SECURE. > > Should we switch glibc's getentropy to GRND_EXPLICIT? Or something > else? > > I don't think we want to print a kernel warning for this function. > Contemplating this question, I think the answer is that we should just not introduce GRND_EXPLICIT or anything like it. glibc is going to have to do *something*, and getentropy() is unlikely to just go away. The explicitly documented semantics are that it blocks if the RNG isn't seeded. Similarly, FreeBSD has getrandom(): https://www.freebsd.org/cgi/man.cgi?query=getrandom&sektion=2&manpath=freebsd-release-ports and if we make getrandom(..., 0) warn, then we have a situation where the *correct* (if regrettable) way to use the function on FreeBSD causes a warning on Linux. Let's just add GRND_INSECURE, make the blocking mode work better, and, if we're feeling a bit more adventurous, add GRND_SECURE_BLOCKING as a better replacement for 0, convince FreeBSD to add it too, and then worry about deprecating 0 once we at least get some agreement from the FreeBSD camp.
