From: David Jander <david@protonic.nl>
To: ptxdist@pengutronix.de
Cc: Robin van der Gracht <robin@protonic.nl>,
Michael Olbrich <m.olbrich@pengutronix.de>,
Marc Kleine-Budde <mkl@pengutronix.de>,
Han Sirkstra <han@protonic.nl>
Subject: [ptxdist] Python 3.5 and the use of getrandom() system call
Date: Fri, 18 Nov 2016 14:21:36 +0100 [thread overview]
Message-ID: <20161118142136.522f66c2@erd980> (raw)
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
next reply other threads:[~2016-11-18 13:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-18 13:21 David Jander [this message]
2016-11-18 17:15 ` Clemens Gruber
2016-11-19 1:23 ` Roland Hieber
2016-11-21 7:24 ` David Jander
2016-11-29 8:56 ` Alexander Dahl
2016-11-29 9:33 ` Michael Olbrich
2016-11-29 13:14 ` Clemens Gruber
2016-11-29 13:41 ` Alexander Dahl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161118142136.522f66c2@erd980 \
--to=david@protonic.nl \
--cc=han@protonic.nl \
--cc=m.olbrich@pengutronix.de \
--cc=mkl@pengutronix.de \
--cc=ptxdist@pengutronix.de \
--cc=robin@protonic.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox