On Mon, Sep 23, 2019 at 11:33:21AM -0700, Andy Lutomirski wrote: > 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, ... This is what's now done in the just-submitted V5, except the "make the blocking mode work better" part: https://lkml.kernel.org/r/20190926204217.GA1366@pc It's a very conservative patch so far IMHO (minus the loud warning). Thanks, -- Ahmed Darwish
