On 17:44 Tue 01 Jul , Apollon Oikonomopoulos wrote:
> Hi,
>
> While trying to debug a segfault in one of Ganeti's Haskell daemons
> (#751886), I came across a memory corruption bug which I can only assume
> comes from the GHC RTS "hijacking" all of GMPs memory management to
> manage it via the SM[1].
>
> As outlined in #751886[2], the said daemon uses FFI calls to libcurl to
> initiate TLS-encrypted communications. Currently, the haskell bindings
> are linked against the GnuTLS version of libcurl, which was recently
> updated to link against gnutls28 instead of gnutls26. gnutls28 uses
> nettle (and thus GMP) for crypto material operations, and what
> *presumably* happens is the following:
>
> 1. A curl multi handler is constructed, with SSL key and certificate
> loaded via gnutls/nettle. Nettle uses GMP's data types to store key
> parameters and the memory of GMP is allocated from GHC's heap[1].
>
> 2. Going back-and-forth between Haskell and C space, eventually a GC
> run is triggered. The GC cannot find Haskell object references to
> the memory allocated by GMP calls via FFI and thus marks it as free.
>
> 3. Some other object takes over the heap chunk and on the next FFI
> call, the SSL keys have been overwritten by random data. The result
> is an unrecoverable SSL error ("Decrypt error"), or worse, a
> segfault.
Annex: I also opened a thread containing useful debugging information in
gnutls-help[1] before finding out what this was all about.
Apollon
[1] http://lists.gnutls.org/pipermail/gnutls-help/2014-June/003535.html
Attachment:
signature.asc
Description: Digital signature