[Security-sig] Can /dev/urandom ever revert from the "good" to the "bad" state?

Nick Coghlan ncoghlan at gmail.com
Thu Jun 23 13:54:53 EDT 2016


On 22 June 2016 at 19:29, Guido van Rossum <guido at python.org> wrote:
> On Wed, Jun 22, 2016 at 7:18 PM, Donald Stufft <donald at stufft.io> wrote:
>> Once, only after boot. On most (all?) modern Linux systems there’s even
>> part of the boot process that attempts to seed the CSPRNG using random
>> values stored during a previous boot to shorten the time window between when
>> it’s ready and when it’s not yet initialized. However, once it is
>> initialized it will never block (or EAGAIN) again.
>
> Then shouldn't it be the responsibility of the boot sequence rather than of
> the Python stdlib to wait for that event? IIUC that's what OS X does (I
> think someone described that it even kernel-panics when it can't enter the
> "good" state).

I spent some time browsing the (mostly-but-not-all public) results of
https://bugzilla.redhat.com/buglist.cgi?quicksearch=getrandom today,
and unfortunately that backed up the results of Ted Ts'o's "what if
/dev/urandom blocked on Linux startup?" experiments [1]. That is,
Linux has the same problem at the distro level that we do at the
language runtime level: the historically permissive behaviour means
that Linux has existing use cases where it's legitimate to start the
init process without waiting for the kernel CSPRNG to be seeded, so
distros can't currently unilaterally prevent the entire OS from
starting just because that subsystem isn't ready yet.

We have a significant advantage that the kernel and distro devs don't
enjoy though, which is a *much* nicer mechanism for runtime error
reporting (in the form of exceptions and tracebacks) - by taking
advantage of that, I believe we can significantly improve the default
behaviour, while also writing a fairly straightforward "if you get
this exception when running on Python 3.6, assess your application's
needs, then apply one of these remedies" note for the Python 3.6
porting guide.

Regards,
Nick.

[1] https://mail.python.org/pipermail/python-dev/2016-June/145146.html

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Security-SIG mailing list