Use of custom memory allocators

Werner Koch wk at
Fri Dec 5 12:41:28 CET 2008

On Fri,  5 Dec 2008 12:04, simon at said:

> Application?  GnuTLS is a library.  We don't want to require all
> applications that use GnuTLS to call libgcrypt explicitly.

Right, this is why we have this GCRYCTL_ANY_INITIALIZATION_P feature.
It allows to do an initialization if the application missed to do it.

> Ok, this would argue for the following solution:
> diff --git a/lib/gnutls_global.c b/lib/gnutls_global.c
> index f59a47f..2c2a91f 100644
> --- a/lib/gnutls_global.c
> +++ b/lib/gnutls_global.c
> @@ -222,8 +222,7 @@ gnutls_global_init (void)
>  	}
>        /* for gcrypt in order to be able to allocate memory */
> -      gcry_set_allocation_handler (gnutls_malloc, gnutls_secure_malloc,
> -	       _gnutls_is_secure_memory, gnutls_realloc, gnutls_free);
> +      gcry_control (GCRYCTL_DISABLE_SECMEM, NULL, 0);

Fine.  This is a proper solution.  If an applications needs to use
secure memory it can do so and gnutls uses it too.  You might want to
state int the manual that gnutls disables the secure memory unless an
application has already initialzied libgcrypt.

> This is the exact same text as above.  What is the difference between
> these two modes?

Sorry, cut and paste error.  It should read:

  If you don't have a need for secure memory, for example if your
  application does not use secret keys or other confidential data or it
  runs in a controlled environment where key material floating around in
  memory is not a problem, you should initialize Libgcrypt this way:
  If you have to protect your keys or other information in memory against
  being swapped out to disk and to enable an automatic overwrite of used
  and freed memory, you need to initialize Libgcrypt this way:

> What does "increased privileges" mean?  Does the application needs to be
> setuid for this to work?  That would also be a non-starter, we can't
> require all applications using GnuTLS to be setuid.

Depends on the number of pages allocated for the secure memory and the
OS.  Current linux version can controll the mlock-able pages with

Right, the application needs to initialize that.  A library can't know
how much secure memory is required.  Another library initialized later
might have a different idea of the required amount of secure memory and
thus it would be unpredictable.  The only solution is that the
application decides and thus initializes libgcrypt.

> That seems like a non-starter for GnuTLS.  If it is important for
> libgcrypt that GnuTLS doesn't initialize libgcrypt, it seems we can't
> really use libgcrypt in GnuTLS.

We discussed that in the past ad nauseam when talking about thread
library initialization.  In contrast to W32, the shared libray system
used in GNU/Linux is not up to handle certain tasks.  The problem is
elevated by using libraries indirectly
(app->libfoo->libldap->libgnutls->libgcrypt->libc) without APP being
aware that it uses libgnutls.  As soon as a library needs a specific
global initialization you need to pass the intialization up to the

For libgcrypt we found a somewhat working solution using
GCRYCTL_INITIALIZATION_FINISHED_P.  It allows a default to catch the
naive use of crypto without the need for specific initialization.

> This is what GnuTLS is doing now, except it is not printing a warning.
> What use is there in printing a warning?

Except that gnutls does not intialize the secure memory.  Printing a
warning is good to inform the application that it should take care of
initialization.  I agree that for gnutls such a waning does not make
sense if you change the code as you proposed.

> The best would that things just work _and_ be secure.  I don't see why
> it isn't possible to reach that goal here?

See above.  Also think of the case if you do not want to use threads -
all will break if you let the libratry decide which threading model to
use.  We need some state in libgcrypt:  For selftests, for hardware
crypto, for the thread library and so on.



Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.

More information about the Gcrypt-devel mailing list