Colm Buckley added the comment: I've spoken with Ted Ts'o (one advantage of working for Google) and taken a look in the Linux kernel source, and things are actually better than we'd feared.
Firstly, calling getrandom() with GRND_NONBLOCK and a buffer size of less than or equal to 32 bytes will always succeed (so, for the hash seed initialization at least, the EAGAIN logic is superfluous - it's still possibly needed for the general case and other operating systems, though). Secondly, the quality of the getrandom data *before* the kernel PRNG is initialized is still pretty good - it's seeded from a combination of RDRAND, interrupt timing, several kernel parameters like uname -a, and RTC. Ted is confident that at least 24 bytes of real entropy will be present by a few seconds into boot time (due to interrupts etc), and that the predictability of the data will be very low. Finally - note that any network-facing applications are *extremely* unlikely to encounter this issue, as they will be started well after networking and other good entropy sources have started. In particular, getrandom() will no longer block once fastinit has completed (on my system, this was less than one second after kernel load). In other words, I think we are very safe to proceed with changeset 9de508dc4837 + the nonblocking_urandom_noraise.patch Note that this solves the problem for *Linux* - if other operating systems do indeed have blocking /dev/urandom reads, this still needs to be addressed. I am not aware of any reports from non-Linux systems, though. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26839> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
