SIGSEGV with program linked against OpenSSL in an Alpine container

jsha · December 1, 2020, 7:00pm

I have a program that uses the openssl crate (via reqwest). I was building and running it in a Docker container based on Alpine, and found that it would exit with status 139 (indicating SIGSEGV) when setting up the OpenSSL methods. I've put together a minimal reproduction case at

github.com

jsha/openssl-crash/blob/main/src/main.rs

use openssl::ssl::SslMethod;

fn main() {
    println!("start");
    SslMethod::tls();
    println!("end");
}

and

github.com

jsha/openssl-crash/blob/main/Dockerfile

# This works
FROM rust:buster

# This works
#FROM rust:alpine
#ENV OPENSSL_STATIC=true
#RUN apk add libc-dev openssl-dev gdb strace && apk update

# This doesn't
#FROM rust:alpine
#RUN apk add libc-dev openssl-dev gdb strace && apk update

COPY . .
RUN cargo build

As you can see from the Dockerfile, if I build on Buster, or if I build statically on Alpine, things work fine. So clearly there is some problem with loading the dynamic library in the Alpine image. How do I debug this further?

I've confirmed that, inside the Alpine container, libssl does exist and the binary is configured to link it:

# ldd target/debug/openssl-crash
        /lib/ld-musl-x86_64.so.1 (0x7faca41c3000)
        libssl.so.1.1 => /lib/libssl.so.1.1 (0x7faca40e8000)
        libcrypto.so.1.1 => /lib/libcrypto.so.1.1 (0x7faca3e69000)
 # ls -l  /lib/libssl.so.1.1
-rwxr-xr-x    1 root     root        523728 Apr 21  2020 /lib/libssl.so.1.1

jethrogb · December 1, 2020, 8:40pm

I see you're already installing gdb. So you just need to run it with gdb and look at the stack trace.

jsha · December 1, 2020, 10:09pm

Ah, sorry, I forgot to include the stack trace! It looks like the relevant function's address is just set to zeroes, but I don't understand why.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007f62eaa764aa in openssl::ssl::SslMethod::tls ()
    at /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.10.30/src/ssl/mod.rs:313
#2  0x00007f62eaa7625a in openssl_crash::main () at src/main.rs:5

sfackler · December 2, 2020, 12:03am

The x86_64-unknown-linux-musl target statically links to MUSL by default, but Alpine uses a dynamically linked MUSL. Since you're dynamically linking to Alpine's OpenSSL, you're ending up with 2 MUSLs and then things explode from there. You can pass RUSTFLAGS=-C target-feature=-crt-static to have rustc dynamically link to Alpine's MUSL, or build an OpenSSL that also statically links to MUSL (e.g. with openssl's vendored Cargo feature).

jsha · December 2, 2020, 12:14am

This worked beautifully, thank you.