seccomp ratsnets: crypto using threads

[Kurt Roeckx]

On Sat, Nov 25, 2017 at 01:26:18AM -0800, Hal Murray via devel wrote:
> (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

So you've upgraded for an OpenSSL 1.0.2 to 1.1.0. In 1.1.0 we made
changes to the thread support, and assume applications might be
using threads instead of relying on them to set things like
locking up properly. This means that when we initialize a global
variable we use the pthread_once() function, which internally uses
the futex to do that. It's not using threads itself, it's just
making sure that if you use threads things work properly.

I think if you want to use seccomp you can really expect to get
such breakage from time to time when libraries or the kernel change.
Libc might for isntance start to use different syscalls depending
on the running kernel, or just changes in the wey libc does
something. And so everything you link to might cause such changes.


Kurt