headers
Rainer Gerhards | 4 Jun 08:49

GnuTLS and valgrind errors

Hi,

I am now working on sorting the nits out of my syslog/tls
implementation. I am now running the app under valgrind [1]. I see a
number of valgrind errors, for example this memory leak here:

==22504== 256 bytes in 2 blocks are definitely lost in loss record 14 of 31
==22504==    at 0x4A0739E: malloc (vg_replace_malloc.c:207)
==22504==    by 0x304AE328F6: _gnutls_mpi_dprint_lz (in
/usr/lib64/libgnutls.so.13.9.1)
==22504==    by 0x304AE3E47C: _gnutls_dh_set_peer_public (in
/usr/lib64/libgnutls.so.13.9.1)
==22504==    by 0x304AE43819: _gnutls_proc_dh_common_server_kx (in
/usr/lib64/libgnutls.so.13.9.1)
==22504==    by 0x304AE3BB4F: (within /usr/lib64/libgnutls.so.13.9.1)
==22504==    by 0x304AE2AF81: _gnutls_recv_server_kx_message (in
/usr/lib64/libgnutls.so.13.9.1)
==22504==    by 0x304AE273DF: _gnutls_handshake_client (in
/usr/lib64/libgnutls.so.13.9.1)
==22504==    by 0x304AE27F77: gnutls_handshake (in
/usr/lib64/libgnutls.so.13.9.1)
==22504==    by 0x7249300: Connect (nsd_gtls.c:1465)
==22504==    by 0x5631E92: Connect (netstrm.c:269)
==22504==    by 0x40EDDB: TCPSendInit (omfwd.c:302)
==22504==    by 0x40F477: doTryResume (omfwd.c:348)

I see some more, but the real question is has GnuTLS been checked
under a memory debugger? All of what I see may be the result of some
wrong API calls by me [always my first line of thought ;)].
(Continue reading)

Permalink | Reply |
headers
Simon Josefsson | 4 Jun 10:01
Favicon
Gravatar

Re: GnuTLS and valgrind errors

"Rainer Gerhards" <rgerhards <at> gmail.com> writes:

> Hi,
>
> I am now working on sorting the nits out of my syslog/tls
> implementation. I am now running the app under valgrind [1]. I see a
> number of valgrind errors, for example this memory leak here:
>
> ==22504== 256 bytes in 2 blocks are definitely lost in loss record 14 of 31
> ==22504==    at 0x4A0739E: malloc (vg_replace_malloc.c:207)
> ==22504==    by 0x304AE328F6: _gnutls_mpi_dprint_lz (in
> /usr/lib64/libgnutls.so.13.9.1)
> ==22504==    by 0x304AE3E47C: _gnutls_dh_set_peer_public (in
> /usr/lib64/libgnutls.so.13.9.1)
> ==22504==    by 0x304AE43819: _gnutls_proc_dh_common_server_kx (in
> /usr/lib64/libgnutls.so.13.9.1)
> ==22504==    by 0x304AE3BB4F: (within /usr/lib64/libgnutls.so.13.9.1)
> ==22504==    by 0x304AE2AF81: _gnutls_recv_server_kx_message (in
> /usr/lib64/libgnutls.so.13.9.1)
> ==22504==    by 0x304AE273DF: _gnutls_handshake_client (in
> /usr/lib64/libgnutls.so.13.9.1)
> ==22504==    by 0x304AE27F77: gnutls_handshake (in
> /usr/lib64/libgnutls.so.13.9.1)
> ==22504==    by 0x7249300: Connect (nsd_gtls.c:1465)
> ==22504==    by 0x5631E92: Connect (netstrm.c:269)
> ==22504==    by 0x40EDDB: TCPSendInit (omfwd.c:302)
> ==22504==    by 0x40F477: doTryResume (omfwd.c:348)
>
> I see some more, but the real question is has GnuTLS been checked
> under a memory debugger? All of what I see may be the result of some
(Continue reading)

Permalink | Reply |
headers
Simon Josefsson | 5 Jun 22:02
Favicon
Gravatar

Re: GnuTLS and valgrind errors

Btw, I just wrote a new self-test tests/mini.c that does a TLS handshake
without using fork or any other system-specific functions.  It should be
perfect to use as a starting point to find memory leaks...

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=tests/mini.c;hb=HEAD

...however, running valgrind on it right now only prints the 5 "normal"
libgcrypt related memory leaks.

I also ran kcachegrind on it, but the most time-consuming gnutls
function is gnutls_global_deinit which is hardly worth optimizing.  The
majority of time is spent inside libgcrypt doing mpi operations.

I'll try to get time to extend the self-test to test X.509, OpenPGP etc.
It would be nice to test through all of the ciphersuites...  or even
have a big program that calls all functions in gnutls, so we can do
automated code-coverage tests.

/Simon
Permalink | Reply |
headers
Simon Josefsson | 5 Jun 22:47
Favicon
Gravatar

Re: GnuTLS and valgrind errors

I fixed some obvious memory leaks in the self-tests, and now gnutls
passes make check (if you supply it the new libgcrypt.supp) with
valgrind without memory leaks...  at least all self checks except
dhepskself.  I don't have time to investigate whether the dhepskself
implies a memory leak in the library or not, but it is possible.

So this means most normal ways to use GnuTLS won't lead to any memory
leaks.  Of course, if you can trigger any memory leaks, please report
it!  We'll add a new self test for it, to catch any regressions.

/Simon
Permalink | Reply |
headers
Stephane Bortzmeyer | 5 Jun 13:57

Re: GnuTLS and valgrind errors

On Wed, Jun 04, 2008 at 08:52:19AM +0200,
 Rainer Gerhards <rgerhards <at> gmail.com> wrote 
 a message of 40 lines which said:

> I am now working on sorting the nits out of my syslog/tls
> implementation. I am now running the app under valgrind [1]. I see a
> number of valgrind errors, 

Be careful, the next time someone tried to fix a Valgrind error in a
TLS implementation, there was nasty results :-)

http://bugs.debian.org/363516

http://wiki.debian.org/SSLkeys

http://www.fsfe.org/en/fellows/tonnerre/stdout/blind_trust_in_valgrind_the_debian_openssl_vulnerability

http://research.swtch.com/2008/05/lessons-from-debianopenssl-fiasco.html
Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 5 Jun 18:40

Re: Re: GnuTLS and valgrind errors

Stephane Bortzmeyer wrote:

> Be careful, the next time someone tried to fix a Valgrind error in a
> TLS implementation, there was nasty results :-)

> http://www.fsfe.org/en/fellows/tonnerre/stdout/blind_trust_in_valgrind_the_debian_openssl_vulnerability
^^^^^^^^^^
That one has a funny criticism of gnutls.

PS. I won't tell you why it's funny :)
Permalink | Reply |

Gmane