[gnutls-help] Issues with libcurl and GnuTLS 3.2
Apollon Oikonomopoulos
apoikos at debian.org
Tue Jun 24 15:20:54 CEST 2014
Hello,
On 15:13 Mon 23 Jun , Apollon Oikonomopoulos wrote:
> - With the same version of libcurl (7.37.0) linked against gnutls
> 2.12, luxid
> works reliably. Actually the bug appeared when Debian switched to a gnutls
> 3.2-linked version of libcurl. I tried out different combinations of
> libcurl and GnuTLS versions, the only failing combinations were with
> GnuTLS 3.2.
>
> --- Backtrace
>
> #0 0x00007fcce89d0002 in __gmpn_powm () from /usr/lib/x86_64-linux-gnu/libgmp.so.10
> No symbol table info available.
> #1 0x00007fcce8997a8d in __gmpz_powm () from /usr/lib/x86_64-linux-gnu/libgmp.so.10
> No symbol table info available.
> #2 0x00007fcce59fdbf2 in _nettle_rsa_blind (pub=pub at entry=0x7fff9b21a230, random_ctx=random_ctx at entry=0x0, random=random at entry=0x7fcce73ec5e0 <rnd_func>, c=c at entry=0x7fff9b21a220, ri=ri at entry=0x7fff9b21a1b0) at rsa-blind.c:56
> r = {{_mp_alloc = 33, _mp_size = 32, _mp_d = 0x7fcce470f9b8}}
The good news is that this is no GnuTLS bug.
For future reference, the problem seems to be in GMP's memory
management: GHC by default uses GMP for its Integer and Fractional
implementation[1]; binaries produced by GHC embed the GHC runtime and
are linked with libgmp. GMP in turn uses a per-process memory heap,
which in the GHC RTS case is managed by the Haskell garbage collector
using mp_set_memory_functions((*alloc)(), (*realloc)(),
(*dealloc)())[1]. The Garbage Collector in turn probably assumes that
this heap should contain Haskell objects known to itself exclusively.
Now, gnutls28 pulls in and uses libgmp as well (via nettle), but this
use is opaque to the Haskell garbage collector, since the gmp function
calls happen way below the GHC runtime and their results are not bound
to Haskell objects. Eventually a Haskell GC run will overwrite the data
used by any FFI calls to libraries using GMP themselves, causing
extensive memory corruption of the key material as seen in the
backtrace. This explains both, the segfaults and the "Decrypt errors"
encountered.
gnutls26 does not use nettle/GMP and that is why the problem does not
manifest.
[1] https://ghc.haskell.org/trac/ghc/wiki/ReplacingGMPNotes
Regards,
Apollon
More information about the Gnutls-help
mailing list