On Fri, Sep 20, 2019 at 6:46 AM Ahmed S. Darwish <darwish.07@xxxxxxxxx> wrote: > > Hi, > > On Wed, Sep 18, 2019 at 04:57:58PM -0700, Linus Torvalds wrote: > > On Wed, Sep 18, 2019 at 2:17 PM Ahmed S. Darwish <darwish.07@xxxxxxxxx> wrote: > > > > > > Since Linux v3.17, getrandom(2) has been created as a new and more > > > secure interface for pseudorandom data requests. It attempted to > > > solve three problems, as compared to /dev/urandom: > > > > I don't think your patch is really _wrong_, but I think it's silly to > > introduce a new system call, when we have 30 bits left in the flags of > > the old one, and the old system call checked them. > > > > So it's much simpler and more straightforward to just introduce a > > single new bit #2 that says "I actually know what I'm doing, and I'm > > explicitly asking for secure/insecure random data". > > > > And then say that the existing bit #1 just means "I want to wait for entropy". > > > > So then you end up with this: > > > > /* > > * Flags for getrandom(2) > > * > > * GRND_NONBLOCK Don't block and return EAGAIN instead > > * GRND_WAIT_ENTROPY Explicitly wait for entropy > > * GRND_EXPLICIT Make it clear you know what you are doing > > */ > > #define GRND_NONBLOCK 0x0001 > > #define GRND_WAIT_ENTROPY 0x0002 > > #define GRND_EXPLICIT 0x0004 What is this GRND_EXPLICIT thing? A few weeks ago, I sent a whole series to address this, and I obviously didn't cc enough people. I'll resend a rebased version today. Meanwhile, some comments on this whole mess: As I think everyone mostly agrees in this whole thread, getrandom() can't just magically start returning non-random results. That would be a big problem. Linus, I disagree that blocking while waiting for randomness is an error. Sometimes you want to generate a key, you want to finish as quickly as possible, and you don't want to be in the business of fiddling with the setup of the kernel RNG. I would argue that *most* crypto applications are in this category. I think that the kernel should, instead, handle this mess itself. As a first pass, it could be as simple as noticing that someone is blocking on randomness and kicking off a thread that does some randomish reads to the rootfs. This would roughly simulate the old behavior in which an ext4 rootfs did more IO than necessary. A fancier version would, as discussed in this thread, do more clever things. (As an aside, I am not a fan of xoring or adding stuff to the CRNG state. We should just use an actual crypto primitive for this. Accumulate the state in a buffer and SHA-512 it. Or use something like the Keccak duplex sponge. But this is a discussion for another day.) So I'm going to resend my series. You can all fight over whether the patch that actually goes in should be based on my series or based on this patch. --Andy
