Hi all, I have noticed that on embedded Linux systems, the kernel can apparently take a significant amount of time to gather enough entropy to successfully initialize the "nonblocking random pool". This leads to any python (3.5) scripts or applications started on boot to hang for that time, because the python executable uses the getrandom() system call to initialize hashing functions and whatnot.
Theoretically there are not so many use-cases I can think of that would require crypto-quality randomness in a python application on an embedded system, and probably fast boot times are more important than good randomness. For this reason I would like to know if anyone knows a better solution than adding the following patch: --- /dev/null +++ b/patches/Python-3.5.0/0003-force-use-of-dev-urandom.patch @@ -0,0 +1,33 @@ +Index: Python-3.5.0/configure.ac +=================================================================== +--- Python-3.5.0.orig/configure.ac ++++ Python-3.5.0/configure.ac +@@ -5123,8 +5123,7 @@ AC_LINK_IFELSE( + AC_MSG_RESULT($have_getrandom_syscall) + + if test "$have_getrandom_syscall" = yes; then +- AC_DEFINE(HAVE_GETRANDOM_SYSCALL, 1, +- [Define to 1 if the Linux getrandom() syscall is available]) ++ echo "WARNING: forced use of /dev/urandom over syscall getrandom()" >&AS_MESSAGE_FD + fi + + # generate output files +@@ -5148,4 +5147,5 @@ echo "creating Makefile" >&AS_MESSAGE_FD + $SHELL $srcdir/Modules/makesetup -c $srcdir/Modules/config.c.in \ + -s Modules Modules/Setup.config \ + Modules/Setup.local Modules/Setup ++ + mv config.c Modules +Index: Python-3.5.0/configure +=================================================================== +--- Python-3.5.0.orig/configure ++++ Python-3.5.0/configure +@@ -16027,7 +16027,7 @@ $as_echo "$have_getrandom_syscall" >&6; + + if test "$have_getrandom_syscall" = yes; then + +-$as_echo "#define HAVE_GETRANDOM_SYSCALL 1" >>confdefs.h ++echo "WARNING: forced use of /dev/urandom over syscall getrandom()" >&6 + + fi + Or similar, to force python to use /dev/urandom instead. Or is there a way (that I ignore) to speed-up the generation of entropy in the Linux kernel? If everyone agrees that this patch is the way to go, I'll arrange a formal patch to be sent to this list. Best regards, -- David Jander Protonic Holland. _______________________________________________ ptxdist mailing list ptxdist@pengutronix.de
