mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
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

             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