seccomp ratsnets: crypto using threads

[Hal Murray]

An interesting tangle.  I'm cleaning up odds and ends, including upgrading 
Raspberry Pi-s to Stretch.  One of them dies with a SIGSYS trap.

It's dieing on 240 which is futex.  That's locks, only needed if you are 
using threads.  This system was built with --disable_dns_lookup, so there 
shouldn't be any thread activity.  There is a block of slots in the seccomp 
list that is ifdef-ed out when ENABLE_DNS_LOOKUP is not defined.  futex is in 
there.

A breakpoint says the crypto stuff is using futex.  See below.

Does anybody understand this area? 

wscript has code that looks interesting:
    if not ctx.options.disable_dns_lookup:
        from wafhelpers.check_pthread import check_pthread_run
        check_pthread_run(ctx)

I haven't checked that code.

The link step for ntpd in waf build -v shows -lpthread.  I can't find any 
thread stuff on the compile steps.

The simple fix is to remove the ifdef around the block of calls needed by 
threads, but that doesn't seem right.

A simpler fix that has predictable long term results is to give up on seccomp 
and rip it all out so we don't have to screw around this things like this.

---------

Program received signal SIGSYS, Bad system call.
0x76ebf104 in futex_wake (private=0, processes_to_wake=2147483647, 
    futex_word=0x76eaf618) at ../sysdeps/unix/sysv/linux/futex-internal.h:231
231     ../sysdeps/unix/sysv/linux/futex-internal.h: No such file or 
directory.
(gdb) bt
#0  0x76ebf104 in futex_wake (private=0, processes_to_wake=2147483647, 
    futex_word=0x76eaf618) at ../sysdeps/unix/sysv/linux/futex-internal.h:231
#1  __pthread_once_slow (once_control=0x76eaf618, init_routine=0x76de9f50)
    at pthread_once.c:127
#2  0x76e21fbc in CRYPTO_THREAD_run_once ()
   from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1
#3  0x76dea538 in OPENSSL_init_crypto ()
   from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1
#4  0x76de4098 in EVP_get_digestbyname ()
   from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1
#5  0x00428f48 in authreadkeys (file=file at entry=0x454670 "/etc/ntp/ntp.keys")
    at ../../libntp/authreadkeys.c:159
#6  0x00427c30 in getauthkeys (keyfile=0x45ee38 "/etc/ntp/ntp.keys")
    at ../../ntpd/ntp_util.c:839


-- 
These are my opinions.  I hate spam.