14.09.2019 21:30, Linus Torvalds пишет: > On Sat, Sep 14, 2019 at 8:02 AM Ahmed S. Darwish wrote: >> >> On Thu, Sep 12, 2019 at 12:34:45PM +0100, Linus Torvalds wrote: >>> >>> An alternative might be to make getrandom() just return an error >>> instead of waiting. Sure, fill the buffer with "as random as we can" >>> stuff, but then return -EINVAL because you called us too early. >> >> ACK, that's probably _the_ most sensible approach. Only caveat is >> the slight change in user-space API semantics though... >> >> For example, this breaks the just released systemd-random-seed(8) >> as it _explicitly_ requests blocking behvior from getrandom() here: >> > > Actually, I would argue that the "don't ever block, instead fill > buffer and return error instead" fixes this broken case. > >> => src/random-seed/random-seed.c: >> /* >> * Let's make this whole job asynchronous, i.e. let's make >> * ourselves a barrier for proper initialization of the >> * random pool. >> */ >> k = getrandom(buf, buf_size, GRND_NONBLOCK); >> if (k < 0 && errno == EAGAIN && synchronous) { >> log_notice("Kernel entropy pool is not initialized yet, " >> "waiting until it is."); >> >> k = getrandom(buf, buf_size, 0); /* retry synchronously */ >> } > > Yeah, the above is yet another example of completely broken garbage. > > You can't just wait and block at boot. That is simply 100% > unacceptable, and always has been, exactly because that may > potentially mean waiting forever since you didn't do anything that > actually is likely to add any entropy. > >> if (k < 0) { >> log_debug_errno(errno, "Failed to read random data with " >> "getrandom(), falling back to " >> "/dev/urandom: %m"); > > At least it gets a log message. > > So I think the right thing to do is to just make getrandom() return > -EINVAL, and refuse to block. Let me repeat: not -EINVAL, please. Please find some other error code, so that the application could sensibly distinguish between this case (low quality entropy is in the buffer) and the "kernel is too dumb" case (and no entropy is in the buffer). -- Alexander E. Patrakov