Colm Buckley added the comment:
Just to re-state; I think we have three problems:
1) _Py_HashSecret initialization blocking. Affects all Python invocations;
already a substantial issue on Debian testing track (90s startup delay).
* there seems to be general agreement that this does not need
Colm Buckley added the comment:
@pitti -
We already discussed this; there are cases where it's not practical to set an
environment variable. The discussion eventually converged on "it is not
desirable that Python should block on startup, regardless of system RNG status".
Re: the
Colm Buckley added the comment:
@haypo - I concur with all of your comments. I didn't have a strong opinion on
whether to modify getrandom_works; your proposal looks fine to me (and will
give consistent behavior over the lifetime of the process).
Thanks all for your help with this issue; much
Colm Buckley added the comment:
To clarify what the various patches do:
3.5.1 as released: os.urandom and hash secret initialization both attempt
getrandom() in preference to reading /dev/urandom. Under certain circumstances,
this will block, possibly indefinitely.
Changeset 9de508dc4837
Colm Buckley added the comment:
Donald -
Oh, that's interesting; thank you. I guess that system-crontab-generator is
being called before that in the boot process.
The most common trigger case, I guess, will then be cloud containers and VMs
which are spun up for single applications. I think
Colm Buckley added the comment:
[[ Larry - thanks for the Mercurial pointers. I was starting from the Debian
sources because I initially assumed this was a Debian problem. Will switch to
hg in future. ]]
--
___
Python tracker <
Colm Buckley added the comment:
Ted -
I'd suggest the following to test.
Boot an arbitrary Linux system with init=/usr/bin/python3 (assuming filesystems
mounted etc). Python 3.5.1 (on Linux) will call getrandom() in blocking mode
very early in its startup; if this happens before the pool
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
Colm Buckley added the comment:
Donald: please note - the current behavior is that Python *will not start at
all* if getrandom() blocks (because the hash secret initialization fails). If
you are relying on the current behavior with a functioning application, then
you are invoking it well
Colm Buckley added the comment:
Here's where things stand, as I currently see it.
Under certain circumstances, under Linux at least, calls to getrandom() will
block. Specifically, they will block if the system's PRNG has been
insufficiently initialized. Depending on the nature of the host
Colm Buckley added the comment:
I have no objection to *deliberate* invocations of the system RNG blocking if
needed. Presumably this behavior can be codified into the various APIs.
My objection is *entirely* to _PyRandom_Init() calling a potentially-blocking
RNG source, before script parsing
Colm Buckley added the comment:
Victor -
I see three options for 3.5.2:
* continue with the 3.5.1 behaviour, which blocks all python invocations in
low-entropy situations. I think this is highly undesireable.
* apply my patches, which fixes the hash secret initialization but not 'import
Colm Buckley added the comment:
Donald -
With the greatest respect, you're talking about introducing multi-minute delays
into the startup times of hundreds of millions of systems, regardless of
whether they have a proximate requirement for cryptographically-secure RNG
sources. I don't think
Colm Buckley added the comment:
Christian -
I would like to make one further comment:
The only reason getrandom() was used instead of /dev/random was to avoid
wasting a file descriptor. The previous behavior was in use for many years with
no security issues; it was changed for FD
Colm Buckley added the comment:
The attached patch (against tip) is a very quick attempt to implement the
desired behavior:
* add a "nonblocking" argument to py_getrandom()
* dev_urandom_python() sets this to 0, to request blocking operation
* dev_urandom_noraise() sets this to 1
Colm Buckley added the comment:
... the script is /lib/systemd/system-generators/systemd-crontab-generator,
although that's not hugely germane to the discussion. Arranging for
PYTHONHASHSEED to be set while it's called wouldn't be impossible of course,
although a command-line flag would
Colm Buckley added the comment:
Christian -
Please note: this is *not* just a VM/cloud issue. This is observed on physical
standalone systems.
The issue (on Debian) is that the Python script is called very early in
the boot process; in particular before most hardware initialization
Colm Buckley added the comment:
Donald -
To be clear - no import of random or of hashlib is required to trigger this
issue. The null script alone triggers the issue; the Python hash secret is
initialized at startup regardless of script contents.
Yes, there is a race condition at system boot
Colm Buckley added the comment:
Larry -
I see at least two issues here, although they are related:
* blocking initialization of the hash secret. This occurs regardless of script
contents; at present Python simply can't be used at all in low-entropy
situations. I feel that this issue
Colm Buckley added the comment:
@larry -
Thank you for joining in. I'm uploading a third version of the patch (against
clean 3.5.1 source, with correct whitespace and a less confusing comment) which
implements the following:
* configure.ac / pyconfig.h.in : looks for linux/random.h and sets
Colm Buckley added the comment:
@larry
Short version; I'm not set up on HG and don't have enough time to get there
from here. The patch I submitted applies cleanly to the HG tip as of 15 minutes
ago (rev 101768) with only offset changes; the attached v4 version includes the
necessary offset
Colm Buckley added the comment:
Larry -
To the first point:
The combination of Victor's changeset 9de508dc4837 (based on my patch) and my
most recent nonblocking_urandom_noraise patch (which is on top of 9de508dc4837)
will do what you suggest for the hash secret initialization - ie
Colm Buckley added the comment:
Larry -
Regardless of the behavior of os.urandom (and 'import random'), is it agreed
that the current state of _PyRandom_Init is acceptable for 3.5.2?
The current behavior (as of 9de508dc4837) is that it will never block on Linux,
but could still block
Colm Buckley added the comment:
Victor -
Yes, it is possible for it to block forever - see the test I proposed for Ted
upthread. The triggering case (systemd-crontab-generator) delays for 90
seconds, but is *killed* by systemd after that time; it doesn't itself time out.
Colm
Colm Buckley added the comment:
@haypo - just wondering where things stand with this? Is this patch going to
get pushed to the mainline?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Colm Buckley added the comment:
It's worth noting that this issue now affects every installation of Debian
testing track with systemd and systemd-cron installed; the python program
/lib/systemd/system-generators/systemd-crontab-generator is called very early
in the boot process; it imports
Colm Buckley added the comment:
The attached patch (against 20160330) addresses the issue for me on Linux; it
has not been tested on other platforms. It adds the GRND_NONBLOCK flag to the
getrandom() call and sends the appropriate failure return if it returns due to
lack of entropy
Colm Buckley added the comment:
@haypo - yes, I think you're right. Can you delete those two lines (or I can
upload another version if you prefer).
I think the pragmatic thing here is to proceed by reading /dev/urandom (as
we've discussed). It's not safe to raise an exception in py_getrandom
Colm Buckley added the comment:
A couple of things to note:
* Despite the earlier title; this does not just apply to VMs; any system with a
potentially-blocking getrandom() (including all Linux 3.17+ and Solaris 11+) is
affected.
* It's true that getrandom() only blocks on Linux when called
Colm Buckley added the comment:
@haypo - yes, it's strange that Linux's getrandom() might block even when
reading the urandom pool. However, I think we need to just cope with this and
add the GRND_NONBLOCK flag rather than attempting to force a change in the
Linux kernel
Colm Buckley added the comment:
@haypo - new version of patch attached with comments and references per your
request.
--
Added file: http://bugs.python.org/file42842/getrandom-nonblocking-v2.patch
___
Python tracker <rep...@bugs.python.org>
Colm Buckley added the comment:
Oh; it's not actually hashlib which is calling getrandom(), it's the main
runtime - the initialization of the per-process secret hash seed in
_PyRandom_Init
Don't know enough about the internal logic here to comment on what the Right
Thing is; but I second
Colm Buckley added the comment:
See https://lwn.net/Articles/606141/ for an explanation of the blocking
behavior of getrandom(). This makes sense to me - before the pool has
initialized, /dev/urandom will be readable but will return highly predictable
data - ie: it should not be considered
33 matches
Mail list logo
