We could say that waiting 6 minutes (using /dev/random) instead of 3 minutes (using getrandom()) is acceptable, but now what if you have 10 soft wanting to do that, /dev/random might block again
This thread is a dialogue of the deaf and a strawman burning fest, and if you keep thinking the other party is a noob, keep assuming the problem is that they're not properly understanding what you're saying, and keep providing the same references that they know by heart, you will get nowhere very fast. The real issue here is that getrandom() introduces a behaviour that is *not* obtainable by the filesystem API. Arguably, it's the correct behaviour, yes; but it still requires the system call - and thus, a new applet. And historically, the filesystem API (i.e. writing to / reading /dev/random and /dev/urandom) was supposed to be _all that userspace needs_ to get random data. So the question is, why the heck isn't it possible to rely on the filesystem API to get the correct behaviour? Why are there two separate entropy pools for /dev/random and /dev/urandom? If there were a single, shared, entropy pool, I could read a character on /dev/random, and when I get this character, it means there's enough entropy and then I can read /dev/urandom for the rest of the lifetime of the system. Since the entropy pools are separated, and /dev/urandom never blocks, then I have no simple filesystem API to block until /dev/urandom gets properly seeded. As you say, I have to rely on the getrandom() system call to do this. This is bad. This goes against the current (and, IMHO, desirable) trend of privileging filesystem APIs over system calls. Applications should be able to just read /dev/urandom and not care about all this. (Except in the case of fd exhaustion, but applications that use randomness should reserve a fd for /dev/urandom opening, and system-wide fd exhaustion is a rare issue - and if it happens to you, getrandom() isn't going to save you, the issue will manifest at some point later.) So, I would say the right thing is to run getrandom() once, in the machine's init scripts, and make sure that all applications that use /dev/urandom are only run after the unique getrandom() invocation returns. Yay, a system call that is meant to be used *once* in the lifetime of the machine. Of course, new applications can be written using getrandom()... if they forsake portability, thanks Linux. All in all, I think your applet is useful, yes. But it is useful *once*, at boot time; and if Linux cared to refactor the way it handles entropy, so that /dev/random could be used to block until /dev/urandom is safe, then your applet (and also getrandom(), because screw fd exhaustion) would not be needed at all. In theory I'd rather fix the problem where it lies, i.e. in the kernel, but in practice it would imply bringing that up on lkml and wasting a few months on bikeshedding for a very uncertain result - so instead, as much as I loathe it, adding a bugware applet to Busybox is a lot easier. Everybody now knows exactly what it's about, so please, stop splaining (and others, myself included, stop flaming); and let Denys arbitrate. -- Laurent _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
