This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Fallback to dev_urandom doesn't work when py_getrandom returns -1
Type: Stage:
Components: Build Versions: Python 3.6, Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: jernejs, vstinner
Priority: normal Keywords: patch

Created on 2018-01-17 13:11 by jernejs, last changed 2022-04-11 14:58 by admin.

Files
File name Uploaded Description Edit
random_fallback.patch jernejs, 2018-01-17 13:11
Messages (5)
msg310158 - (view) Author: Jernej Simončič (jernejs) * Date: 2018-01-17 13:11
I'm playing with Gentoo in LXC running on ARM-based QNAP NAS, and when trying to compile Python 3.5.4, the build failed with "Fatal Python error: failed to get random numbers to initialize Python" (full details at https://forums.gentoo.org/viewtopic-p-8172124.html ).

glibc in the environment is 2.25 (supports getrandom), while kernel is 3.10 (doesn't support getrandom).

Looking at random.c, pyurandom returns -1 instead of falling back to dev_urandom when py_getrandom returns -1, so the attached fix is simple.
msg310162 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-01-17 13:40
> I'm playing with Gentoo in LXC running on ARM-based QNAP NAS, and when trying to compile Python 3.5.4, the build failed with "Fatal Python error: failed to get random numbers to initialize Python" (full details at https://forums.gentoo.org/viewtopic-p-8172124.html ).

I'm surprised. Python 3.5.4 does contain my latest fix: commit 035ba5da3e53e45c712b39fe1f6fb743e697c032 (bpo-29157).

> Looking at random.c, pyurandom returns -1 instead of falling back to dev_urandom when py_getrandom returns -1, so the attached fix is simple.

Ignoring failures is not a good idea.

What is the result of the getrandom() function?

> glibc in the environment is 2.25 (supports getrandom), while kernel is 3.10 (doesn't support getrandom).

I expect n < 0 with errno = ENOSYS: py_getrandom() should return 0 in this case, not -1.
msg310196 - (view) Author: Jernej Simončič (jernejs) * Date: 2018-01-17 16:45
OK, looks like Qnap is doing something weird there - calls to getrandom result in EFAULT, which results in . PHP had the same problem: https://bugs.php.net/bug.php?id=75409

Changing "if (errno == ENOSYS || errno == EPERM) {" to "if (errno == ENOSYS || errno == EPERM || errno == EFAULT) {" also works.
msg310197 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-01-17 17:03
OK, looks like Qnap is doing something weird there - calls to getrandom result in EFAULT

Aha, first time that I see this error on getrandom().

Is it a kernel change? A libc change? Is Qnap a kind of sandbox?
msg310206 - (view) Author: Jernej Simončič (jernejs) * Date: 2018-01-17 20:52
Qnap is a NAS, and while I'm running Gentoo inside LXC, EFAULT is returned by getrandom syscall even in the host OS. The model I'm doing this on is TS-228, uname -a of the host OS reports:

Linux qnap 3.10.20-al-2.5.3 #67 SMP PREEMPT Sat Dec 30 04:29:34 CST 2017 armv7l unknown

This is with the latest firmware installed as of this writing - 4.3.4.0435 (30.12.2017).
History
Date User Action Args
2022-04-11 14:58:56adminsetgithub: 76761
2018-01-17 20:52:10jernejssetmessages: + msg310206
2018-01-17 17:03:55vstinnersetmessages: + msg310197
2018-01-17 16:45:37jernejssetmessages: + msg310196
2018-01-17 13:40:05vstinnersetnosy: + vstinner
messages: + msg310162
2018-01-17 13:11:08jernejscreate