Hi, It was reported that nettle crashes with SIGILL on an armv7 system. I've gather some info from the report [0], but let me know if you need anything else. My hunch is that this is neon related, and that the system that was used for compilation supported it but the final system doesn't. I'll disable neon support in the fedora builds and see how it works out.
The instruction that fails is:
(gdb) x/i$pc => 0xb6647af8 <_nettle_salsa20_core+8>: vldmia r12, {d20-d25}
And the backtrace is:
(gdb) backtrace #0 _nettle_salsa20_core () at salsa20-core-internal.s:58 #1 0xb6647db4 in nettle_salsa20r12_crypt (ctx=ctx@entry=0xb6cc7f40 <nonce_ctx>, length=<optimized out>, length@entry=29, c=c@entry=0x7f67ce83 "", m=m@entry=0x7f67ce83 "") at salsa20r12-crypt.c:65 #2 0xb6c9b1e0 in wrap_nettle_rnd_nonce (_ctx=<optimized out>, datasize=29, data=0x7f67ce83) at rnd.c:302 #3 wrap_nettle_rnd (_ctx=<optimized out>, level=level@entry=0, data=0x7f67ce83, datasize=datasize@entry=29) at rnd.c:321 #4 0xb6bcdd2c in _gnutls_rnd (len=29, data=<optimized out>, level=GNUTLS_RND_NONCE) at ./random.h:37 #5 create_tls_random (dst=<optimized out>) at gnutls_handshake.c:205 #6 0xb6bce0e0 in _gnutls_set_client_random (session=<optimized out>, rnd=<optimized out>) at gnutls_handshake.c:230 #7 0xb6bcf460 in send_client_hello (again=<optimized out>, session=0x7f67ce38) at gnutls_handshake.c:2039 #8 send_hello (session=session@entry=0x7f67ce38, again=<optimized out>) at gnutls_handshake.c:2249 #9 0xb6bd2ca4 in handshake_client (session=0x7f67ce38) at gnutls_handshake.c:2732 #10 gnutls_handshake (session=0x7f67ce38) at gnutls_handshake.c:2583 #11 0xb6f9a9d8 in cstp_handshake (vpninfo=vpninfo@entry=0x7f58ccf8, init=64, init@entry=1) at gnutls.c:2250 #12 0xb6f9aff8 in openconnect_open_https (vpninfo=vpninfo@entry=0x7f58ccf8) at gnutls.c:2227 #13 0xb6f7cc70 in do_https_request (vpninfo=vpninfo@entry=0x7f58ccf8, method=0xb6f9f700 "POST", method@entry=0xb6ffec80 <__stack_chk_guard> "", request_body_type=request_body_type@entry=0xb6f9fa28 "application/x-www-form-urlencoded", request_body=request_body@entry=0x7f58d480, form_buf=0xbefff25c, form_buf@entry=0x1bb, fetch_redirect=fetch_redirect@entry=0) at http.c:875 #14 0xb6f8d1a0 in cstp_obtain_cookie (vpninfo=<optimized out>) at auth.c:1238 #15 0x7f559508 in main (argc=0, argv=0x0) at main.c:1388
[0]. The full report: https://bugzilla.redhat.com/show_bug.cgi?id=1287298#c10
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
It was reported that nettle crashes with SIGILL on an armv7 system. I've gather some info from the report [0], but let me know if you need anything else.
It would be good to know how nettle was built, configure flags, configure output, etc. And which version.
My hunch is that this is neon related, and that the system that was used for compilation supported it but the final system doesn't.
That's a possible explanation, by default neon would be enabled if it's supported on the build system.
I'll disable neon support in the fedora builds and see how it works out.
For a binary distribution, it should be built with --disable-arm-neon, or --enable-fat. If the failing library *was* built with --enable-fat, there might be some problem with the run-time detection.
Let me know if it solves the problem.
Regards, /Niels
On Wed, Dec 2, 2015 at 8:53 PM, Niels Möller nisse@lysator.liu.se wrote:
It was reported that nettle crashes with SIGILL on an armv7 system. I've gather some info from the report [0], but let me know if you need anything else.
It would be good to know how nettle was built, configure flags, configure output, etc. And which version.
My hunch is that this is neon related, and that the system that was used for compilation supported it but the final system doesn't.
That's a possible explanation, by default neon would be enabled if it's supported on the build system.
I'll disable neon support in the fedora builds and see how it works out.
For a binary distribution, it should be built with --disable-arm-neon,
Done that and it fixed the issue. The user had no neon support in the CPU.
or --enable-fat. If the failing library *was* built with --enable-fat, there might be some problem with the run-time detection.
I plan to use --enable-fat on fedora. I seem to have some issues with 3.1.1 (crashes on x86_64) when a "hardened" build is enabled (https://fedoraproject.org/wiki/Changes/Harden_All_Packages). I will investigate further.
regards, Nikos
Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
I plan to use --enable-fat on fedora. I seem to have some issues with 3.1.1 (crashes on x86_64) when a "hardened" build is enabled (https://fedoraproject.org/wiki/Changes/Harden_All_Packages). I will investigate further.
It also seems using ifunc is generally flaky (in particular, crashes with RTLD_NOW). So that's disabled on the master branch.
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se