New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AIX build fails with failure to get random numbers #81024
Comments
build fails with: |
robb@nepal:/raid/checkouts-raid/robb/nepal/build-py37$ gmake Makefile:626: recipe for target 'sharedmods' failed |
Could you please use a debugger and step through _Py_HashRandomization_Init and pyurandom to see, where the initialization of the RNG is failing? |
Try to compress config.log to attach it. Or at least attach the output of "./configure" as a file. I'm looking for HAVE_GETRANDOM, HAVE_GETRANDOM_SYSCALL, HAVE_GETENTROPY defines that you can find in pyconfig.h. About /dev/urandom: does this device exist? Is your user allowed to read from it? For example, run "dd if=/dev/urandom of=random bs=1 count=1" command: does it fail? |
from pyconfig.h: /* Define to 1 if the getrandom() function is available */ /* Define to 1 if the Linux getrandom() syscall is available */ /* Define to 1 if you have the <linux/random.h> header file. */ /* Define to 1 if you have the `getentropy' function. */ |
Ok, so Python uses /dev/urandom. Can you try to read a few bytes from it? Like 256 bytes. You can try my dd command. |
Opening /dev/urandom seems to return -1 (dbx) print buffer |
The call to open("/dev/urandom", flags) is returning -1, and errno is set to 22, EINVAL - Invalid argument. could the flags be set incorrectly? |
Reading a few bytes from /dev/urandom via dd: robb@nepal:/raid/checkouts-raid/robb/nepal/build-py37$ dd if=/dev/urandom bs=256 count=1 |
Robert Boehne: pyurandom() uses _Py_open_noraise("/dev/urandom", O_RDONLY) which uses O_CLOEXEC if available. If this flag available? Does it work? Please try to build attached urandom.c. Example on my Fedora 29: open O_RDONLY succeeded |
It doesn't look good: robb@nepal:/raid/checkouts-raid/robb/nepal$ xlc_r -q64 -O0 -g robb@nepal:/raid/checkouts-raid/robb/nepal$ ./urandom open O_RDONLY failed open O_RDONLY | O_CLOEXEC failed robb@nepal:/raid/checkouts-raid/robb/nepal$ uname -a AIX nepal 1 7 00FA7FB84C00 robb@nepal:/raid/checkouts-raid/robb/nepal$ On Thu, May 9, 2019 at 6:21 PM STINNER Victor <report@bugs.python.org>
|
I wonder if there's anyone with AIX 7 who can attempt to reproduce this. We have another AIX machine, but it is down for the moment. I would like to eliminate a problem on this machine as the cause. |
Ah. That sounds like an issue on your machine or specific to AIX. I don't see what Python can do to support a platform where /dev/urandom doesn't work. Python really needs /dev/urandom at startup to initialize its "hash secret" to reduce the risk of DoS attack attack against dict. https://python-security.readthedocs.io/vuln/cve-2012-1150_hash_dos.html Maybe it's a permission issue. Maybe a libc issue. I don't know. But I suggest to close the issue and try to find help from AIX instead. |
I close the issue. Maybe contact Michael Felt to get help to debug your issue. |
FYI: I was contacted this week by someone with this problem. The problem was resolved after they updated AIX (was 7100-04-00-0000). Please note: any oslevel -s reporting six zeros at the end needs the SP that is released in parallel with the base. |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: