"import random" blocks on entropy collection on Linux with low entropy

[matejcik]

BPO	25420
Nosy	@malemburg, @rhettinger, @vstinner, @matejcik, @socketpair, @tpetazzoni
Superseder	bpo-26839: Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()
Files	urandom.patch random.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2016-04-26.12:11:44.887>
created_at = <Date 2015-10-16.13:49:56.307>
labels = ['type-bug', 'library']
title = '"import random" blocks on entropy collection on Linux with low entropy'
updated_at = <Date 2016-04-26.12:11:44.886>
user = 'https://github.com/matejcik'

bugs.python.org fields:

activity = <Date 2016-04-26.12:11:44.886>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2016-04-26.12:11:44.887>
closer = 'vstinner'
components = ['Library (Lib)']
creation = <Date 2015-10-16.13:49:56.307>
creator = 'matejcik'
dependencies = []
files = ['40816', '40820']
hgrepos = []
issue_num = 25420
keywords = ['patch']
message_count = 20.0
messages = ['253073', '253163', '253178', '253180', '253205', '253206', '253209', '253212', '253214', '253222', '253230', '253232', '256913', '256916', '256935', '264227', '264257', '264260', '264262', '264264']
nosy_count = 6.0
nosy_names = ['lemburg', 'rhettinger', 'vstinner', 'matejcik', 'socketpair', 'thomas-petazzoni']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = '26839'
type = 'behavior'
url = 'https://bugs.python.org/issue25420'
versions = ['Python 3.5']

[matejcik]

When imported, the random module creates and seeds an implicit instance, even when it is never used.

The RNG is seeded from os.urandom, which as of python 3.5 uses the potentially blocking getrandom() call.

This causes problems e.g. on our build VMs that don't have true entropy, so getrandom() blocks forever -- unlike /dev/urandom, getrandom() in kernel waits until 128 bits of true entropy are available to reseed the RNG. And as it happens, the usual setup.py will very indirectly "import random" somewhere deep in its dependencies.

I can foresee a similar issue if someone uses python early in the boot process.

A possible workaround is to monkeypatch os.urandom (in this particular case, to return a string of zeroes and remove randomness entirely to get reproducible builds)

[vstinner]

"The RNG is seeded from os.urandom, which as of python 3.5 uses the potentially blocking getrandom() call."

Hum ok, so your issue is specific to Linux.

"This causes problems e.g. on our build VMs that don't have true entropy, so getrandom() blocks forever"

Hum, the problem was already fixed some months/years ago: you must attach a RNG virtio device to your VM. Python is just one example, a lot of applications need entropy.

"A possible workaround is to monkeypatch os.urandom (in this particular case, to return a string of zeroes and remove randomness entirely to get reproducible builds)"

An unsafe *workaround* is to install haveged, a daemon generating entropy using the CPU.

[matejcik]

On 18.10.2015 23:09, STINNER Victor wrote:

Hum ok, so your issue is specific to Linux.

yes, should have specified that, sorry

Hum, the problem was already fixed some months/years ago: you must attach a RNG virtio device to your VM. Python is just one example, a lot of applications need entropy.

i disagree that this is a good solution; similar to your haveged
suggestion, this is a workaround.

Unless a program specifically uses randomness, it should not need to
read any entropy. For the python runtime itself, this is preventable by
setting fixed PYTHONHASHSEED. For random module, there is no clean way
to prevent it.

[vstinner]

If your OS has no entropy at all, you will have much more severe
issue. For example, don't try to generate a SSH key or established a
SSL/TLS session.

[socketpair]

Just install rngd and setup it to user /dev/urandom as entropy source. I think thread is closed :)

[vstinner]

I knew the subtle difference between reading from /dev/urandom and
getrandom() syscall: the syscall hangs until /dev/urandom is feeded with
enough entropy. It should be documented in Whats New, os.urandom and maybe
also random doc. Not only python 3.5 was affected by the issue.

[socketpair]

Man getrandom()

As of Linux 3.19, the following bug exists:

   *  Depending on CPU load, getrandom() does not react to interrupts
      before reading all bytes requested.

So, is it goot to use this syscall now?

[vstinner]

Hi,

Марк Коренберг added the comment:

Man getrandom()

As of Linux 3.19, the following bug exists:

   *  Depending on CPU load, getrandom() does not react to interrupts
      before reading all bytes requested.

So, is it goot to use this syscall now?

I saw a fix proposed on the LKML but it looks like it was not merged.
I don't know what to think about this bug.

getrandom(n, GRND_NONBLOCK) behaviour depends if /dev/urandom was
feeded with enough entropy and the value of n. It should not be
interrupted by signal for n <= 256.

Can you reproduce the bug? Which kind of applications can hang because
of this bug?

I would prefer to continue to use getrandom() syscall on Linux, avoid
using a file descriptor is really useful.

Maybe we can try to document the behaviour of os.urandom() for signal
handling? Or at least redirect users to getrandom() manual page.

[vstinner]

The RNG is seeded from os.urandom, which as of python 3.5 uses the potentially blocking getrandom() call.

Here is a patch for os.urandom() documentation. What do you think?

[matejcik]

let me reiterate that what I consider a bug is the fact that "import random" statement calls os.urandom (which per the proposed documentation may sometimes block)

IOW, "import random" may sometimes block, even though it is not actually used at any point (could be pulled in through some dependencies)

[malemburg]

I think Jan has a point there. An import should not cause the whole interpreter to hang.

Wouldn't it be possible to have the getrandom() call be done lazily to avoid this and only have it block when the RNG from the random is actually being used ?

Or alternatively, make things more robust by avoiding to call the API on systems which are known to have blocking problems and then reverting to using /dev/urandom directly instead ?

Note that the RNG does already use a fallback solution for systems which don't provide os.urandom. Also note that os.urandom() is documented (indirectly via man 4 urandom) to not be blocking. If it blocks on some systems, we should add a work-around for those, just like Python/random.c does for Solaris.

BTW: Is there a way to determine whether enough entropy has been gathered without doing a blocking call ? This could be used to find out whether getrandom() will potentially block.

[matejcik]

attaching a first draft of what i'd consider a solution? not sure if this is the right way to go, and i don't know how to write a test for an import statement