Re: lib/53630: openssl fallout on arm

[Martin Husemann <martin%duskware.de@localhost>]

The following reply was made to PR lib/53630; it has been noted by GNATS.

From: Martin Husemann <martin%duskware.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: lib/53630: openssl fallout on arm
Date: Sun, 30 Sep 2018 11:37:38 +0200

 The SIGILL is not from the cpu features probe sequence (where it is
 guarded by a sigsetjmp), but from:
 
 Thread 2 received signal SIGILL, Illegal instruction.
 0x72d39468 in _armv7_tick () from /usr/lib/libcrypto.so.14
 (gdb) bt
 #0  0x72d39468 in _armv7_tick () from /usr/lib/libcrypto.so.14
 #1  0x72c6923c in get_timer_bits ()
     at /usr/src/crypto/external/bsd/openssl/dist/crypto/rand/rand_unix.c:647
 #2  rand_pool_add_additional_data (pool=pool@entry=0x728321a0)
     at /usr/src/crypto/external/bsd/openssl/dist/crypto/rand/rand_unix.c:603
 #3  0x72c69554 in rand_drbg_get_additional_data (pout=pout@entry=0x7fe2307c, 
     max_len=<optimized out>)
     at /usr/src/crypto/external/bsd/openssl/dist/crypto/rand/rand_lib.c:291
 #4  0x72c6adc8 in RAND_DRBG_bytes (drbg=0x7284a900, out=0x72818a00 "", 
     outlen=512)
     at /usr/src/crypto/external/bsd/openssl/dist/crypto/rand/drbg_lib.c:652
 #5  0x72ce14d8 in bnrand (flag=PRIVATE, rnd=0x72832158, bits=4096, top=-1, 
     bottom=0)
     at /usr/src/crypto/external/bsd/openssl/dist/crypto/bn/bn_rand.c:46
 #6  0x72ce1720 in bnrand_range (flag=PRIVATE, r=0x72832158, range=0x72832140)
     at /usr/src/crypto/external/bsd/openssl/dist/crypto/bn/bn_rand.c:162
 
 (gdb) info reg
 r0             0x2      2
 r1             0x0      0
 r2             0x2914   10516
 r3             0x72ded500       1927206144
 r4             0x0      0
 r5             0x7fe23008       2145529864
 r6             0x0      0
 r7             0x7284a900       1921296640
 r8             0x728321a0       1921196448
 r9             0x0      0
 r10            0x2      2
 r11            0x7fe2304c       2145529932
 r12            0x72de8f30       1927188272
 sp             0x7fe23008       0x7fe23008
 lr             0x72c6923c       1925616188
 pc             0x72d39468       0x72d39468 <_armv7_tick>
 cpsr           0x20070210       537330192
 
 (gdb) x/16i $pc
 => 0x72d39468 <_armv7_tick>:    mrrc    15, 1, r0, r1, cr14
    0x72d3946c <_armv7_tick+4>:  mov     pc, lr
 
 IIUC this coprocessor access should be allowed by userland if some special
 bit in the process status is set (which it obviously is during the constructor
 run at library load time). Maybe we lose this bit for new threads?
 
 Martin