libbitcoinconsensus issue with libcrypto.so.1.0.0 and spongycastle #6699

In before: this is all new territory for me, so I'll just describe what I think that might be relevant.

I'm experimenting with BitcoinJ and libbitcoinconsensus.

When using the compiled libbitcoinconsensus of the 0.11 release/Gitian build, it seems to work as expected, and the BitcoinJ tests (mvn test) pass.

However, when I use a locally build library, based on the current master (d5d1d2e65a1c3b91452d2428410f701bca1e53cc), then there seems to be some kind of conflict, and the tests break, followed by a core dump:

Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec - in org.bitcoinj.core.DumpedPrivateKeyTest
Running org.bitcoinj.core.ECKeyTest
#
# A fatal error has been detected by the Java Runtime Environment:
#
SUREFIRE-859: #  SIGSEGV (0xb) at pc=0x00007f7d9c823d17, pid=16103, tid=140177711195904
#
# JRE version: Java(TM) SE Runtime Environment (7.0_80-b15) (build 1.7.0_80-b15)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.80-b11 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libcrypto.so.1.0.0+0x67d17]  SHA256_Update+0x157
#
# Core dump written. Default location: /home/dexx/Projects/Java/bitcoinj/core/core or core.16103
#
# An error report file with more information is saved as:
# /home/dexx/Projects/Java/bitcoinj/core/hs_err_pid16103.log
#
SUREFIRE-859: # If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted (core dumped)

Full error report: http://pastebin.com/raw.php?i=ycUcKdM0

This also happens, when I use the 0.10 branch.

BitcoinJ currently uses Spongy Castle 1.51, which is a stripped down version of Bouncy Castle.

I assume this might be related to the OpenSSL version I currently use:

$ openssl version -a
OpenSSL 1.0.1f 6 Jan 2014
built on: Thu Jun 11 15:26:38 UTC 2015
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) 
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

On:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.10
Release:    14.10
Codename:   utopic

If this is indeed related to OpenSSL, and basically out of scope of Bitcoin Core, then I'm wondering, whether there might be a check during the build process, to reject incompatible versions.

It's possible that the libs conflict, but I don't know enough about java/jna to speculate about how its symbols are resolved.

The relevant difference between the release version of libbitcoinconsensus and your locally-built one is probably that the former statically links openssl, and the locally-built one dynamically links one on your system (you could check this using readelf -a /path/to/libconsensus.so |grep NEEDED).

Likely this gives a symbol collision with one of the libraries used by java - possibly it uses another version of libcrypto internally.

This can be avoided by using the depends system:

cd depends
make NO_QT=1 NO_WALLET=1 NO_UPNP=1  # minimum
cd ..
./configure --prefix=$PWD/depends/x86_64-unknown-linux-gnu
make

This will create a fully self-contained libconsensus, as from the release.

The relevant difference between the release version of libbitcoinconsensus and your locally-built one is probably that the former statically links openssl, and the locally-built one dynamically links one on your system

Ahh, I see. libcrypto is indeed listed in the dynamic section of the locally build version:

 0x0000000000000001 (NEEDED)             Shared library: [libcrypto.so.1.0.0]
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]

Whereby it's missing in the release version:

 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]

Thanks!

Eh, you shouldn't need to static link it... so IMO keep this open even if that workaround helps.

Sure @luke-jr: do you have an idea how to tackle this, or do you need additional information from me?

I'd say this is low priority as a) we know how to mitigate it b) this will go away once secp256k1 is used for verification

Can be closed?

@dcousens Well, it's not fixed ... yet.

@luke-jr I'd say it is; am I missing something?

You mean with in master with libsecp256k1, libconsensus no longer needs/links OpenSSL? I suppose if that's true, then this specific one is fixed, but probably it will just pop up again when someone wants to use libsecp256k1 themselves...?

Yes, in master, libconsensus no longer links with OpenSSL.

The initial issue as described in the first post does indeed not occure anymore.

I'm going to close this and leave it to a maintainer to reopen, if needed.

@sipa for reference, this is what I was referring to when requesting refcounting for secp256k1 init/de-init (thanks for adding that, btw). It'd be great to verify that this scenario works as intended.