On Tue, Jul 12, 2016 at 01:09:42PM -0400, Michael Conrad wrote: > On 7/7/2016 11:49 AM, Rob Landley wrote: > >On 07/06/2016 11:41 AM, Etienne Champetier wrote: > >>>Now you really hate the fact that getrandom() is a syscall. > >I do not hate the fact getrandom is a syscall. I'm asking what the point > >is of a new applet to call this syscall. You have suggested it could > >block to show when /dev/urandom is producing a higher grade of > >randomness than it does before being properly seeded. That is, as far as > >I can tell, the only reason for your new applet to exist rather than > >upgrading $RANDOM in ash/hush. > > > Actually in my opinion the syscall is inferior to a new character > device, because blocking syscalls interfere with event-driven > programming. > > Suppose you want to write a single-thread event-driven web server > which initializes its SSL library with this randomness source (i.e. > won't allow SSL until enough entropy is collected for a good > initialization) but you still want it to be able to accept non-SSL > connections. In order to use the syscall you need a thread, or > child process. (haha, such as pipe to a "getrandom" applet...)
Thanks for contributing your ideas about what color the bikeshed should be, but getrandom's already got you covered. Until your csPRNG is initialized, just call getrandom with the GRND_NONBLOCK once each time you get any event (i.e. each time poll() returns). There's no need to busy-wait or periodically check with timeouts since you don't need the results until there's an event to act on, anyway. There are very good reasons it's a syscall rather than a device: many use cases require a never-fails entropy source, and with the device node approach they're vulnerable to fd-exhaustion attacks. Most existing bad code, when faced with such a situation, falls back to some completely insecure seed like time(). The only reliable way to prevent such idiocy was to provide an interface that can't fail. Rich _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
