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
test_sha256 from test_socket fails on ppc64le arch #75886
Comments
The issue is reproducible on a CentOS 7.4 on ppc64le architecture. It passes successfully on other arch's (however the other power pc arch's might also be affected). How to reproduce: Compile python 3.6 from source. Run ./python3 -m test --verbose test_socket And it fails with: ERROR: test_sha256 (test.test_socket.LinuxKernelCryptoAPI) Traceback (most recent call last):
File "/root/test/cpython/Lib/test/test_socket.py", line 5424, in test_sha256
op.sendall(b"abc")
OSError: [Errno 126] Required key not available |
What is the kernel version? It would be nice to have the strace output. Example: strace -o trace ./python -m test -v test_socket -m test_sha256 I'm surprised because it seems like ENOKEY (error 126) can only be get on accept(), not on send(): |
Forgot the mention the kernel version which is 3.10.0-693.2.1.el7.ppc64le |
Attaching the strace output. |
Charalampos Stratakis: "Attaching the strace output." Oh thanks! I guess tha the interesting syscalls are: socket(AF_ALG, SOCK_SEQPACKET|SOCK_CLOEXEC, 0) = 3 test_socket calls bind() with typ='hash', name='sha256', but in the strace, I only see 'hash'. strace is maybe outdated and fails to display the full bind() address, or Python doesn't serialize correctly the address. -- On my Fedora 26, I see sha256 in the bind call: socket(AF_ALG, SOCK_SEQPACKET|SOCK_CLOEXEC, 0) = 3 |
I vote for this option since I see addrlen=88 in both examples. |
Indeed the version of strace is 'strace-4.12-4.el7'. I will try to provide output from the latest one. |
Attaching the output of: strace -s 128 -e trace=%network -o trace ./python3 -m test -v test_socket -m test_sha256 using the latest version of strace (4.19). |
I seem to be having this issue on CentOS 7.4 but running on x86_64 instead of ppc64le. I have attached an strace using version 4.17 (the lastest version from scl) created as follows: strace -s 128 -e trace=%network -o trace ./python -m test -v test_socket -m test_sha256 == CPython 3.6.3 (default, Oct 13 2017, 11:16:36) [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] ====================================================================== Traceback (most recent call last):
File "/home/ryan/Downloads/Python-3.6.3/Lib/test/test_socket.py", line 5424, in test_sha256
op.sendall(b"abc")
OSError: [Errno 126] Required key not available Ran 1 test in 0.001s FAILED (errors=1) 1 test failed: Total duration: 39 ms |
I've got the same error on CentOS 7.4 on x86_64. --- $ cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
$ uname -a
Linux localhost.localdomain 3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 20 20:32:50 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ strace -V
strace -- version 4.20
Copyright (c) 1991-2017 The strace developers <https://strace.io>.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Optional features enabled: (none) ====================================================================== Traceback (most recent call last):
File "/home/vagrant/sources/Python-3.7.0a2/Lib/test/test_socket.py", line 5580, in test_sha256
op.sendall(b"abc")
OSError: [Errno 126] Required key not available Ran 1 test in 0.006s FAILED (errors=1) 1 test failed: Total duration: 98 ms By contrast, I can get a expected result on Debian: --- $ uname -a
Linux debian-server 4.13.0-1-amd64 #1 SMP Debian 4.13.13-1 (2017-11-16) x86_64 GNU/Linux
$ cd Python-3.7.0a2
$ strace -v -s 128 -e trace=%network -o strace.log ./python -m test -v test_socket -m test_sha256
== CPython 3.7.0a2 (default, Nov 29 2017, 18:47:33) [GCC 7.2.0]
== Linux-4.13.0-1-amd64-x86_64-with-debian-buster-sid little-endian
== cwd: /home/working/Python-3.7.0a2/build/test_python_21000
== CPU count: 24
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 0.07 [1/1] test_socket
test_sha256 (test.test_socket.LinuxKernelCryptoAPI) ... ok Ran 1 test in 0.001s OK Total duration: 43 ms |
Charalampos Stratakis told me that the test pass on kernel 4.11. The bug comes from the kernel, there is nothing that Python can do to workarond this kernel bug. So I suggest to skip the test on kernel < 4.11, or at least skip it on ppc64 with kernel < 4.11. |
Charalampos Stratakis, Ryan Decker, Fomalhaut Weisszwerg:
To test the PR, you can download the PR as a patch and apply it using "patch -p1 < 4643.patch": https://github.com/python/cpython/pull/4643.patch It would be nice to get the exact version in which sha256 was fixed on ppc64, but it's not a requirements. |
Ah, I think that I found the bugfix (8 Jan 2016): So it was fixed in the kernel 4.5. I found also https://access.redhat.com/errata/RHSA-2017:2437 : "The lrw_crypt() function in 'crypto/lrw.c' in the Linux kernel before 4.5 allows local users to cause a system crash and a denial of service by the NULL pointer dereference via accept(2) system call for AF_ALG socket without calling setkey() first to set a cipher key. (CVE-2015-8970, Moderate)" So I will simply skip test_sha256() on all architectures for kernel older than 4.5. You can now ignore my questions in my previous comment ;-) |
STINNER Victor Thank you for your info. And this issue occurs not only ppc64le but also x86_64. Linux localhost.localdomain 3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 20 20:32:50 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux I think that this issue does not depend on arch. |
"And this issue occurs not only ppc64le but also x86_64. (...) I think that this issue does not depend on arch." Thanks for the confirmation. This is what I understood from the Red Hat report, but also the kernel bugfix. test_sha256() is now skipped on all architectures on kernel < 4.5. Thank you for the bug report Charalampos Stratakis! Sorry for the delay, I wasn't sure how to fix it. I didn't know which kernels were impacted, which architectures, and if it was a Python or a kernel bug. (It's definitively a kernel bug.) |
Thanks for the fix Victor! |
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: