Use of custom memory allocators

[Simon Josefsson]

Werner Koch <wk at gnupg.org> writes:

> On Fri,  5 Dec 2008 12:04, simon at josefsson.org 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.

Great.  I got the impression from the documentation that this isn't the
recommend approach though.

>> 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);
>>  
>>        gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 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.

Yup.  And we could also recommend applications to initialize secure
memory if they want.

I'll test the patch above more.

>> 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:
>   
>   [... GCRYCTL_DISABLE_SECMEM ...]
>   
>   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:
>   
>   [... GCRYCTL_INIT_SECMEM ...]

Ah, that makes more sense.

>> 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
> ulimit.
>
> 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.

Ok.  Using the patch above, and documenting this, seems to be the best
we can achieve then.

>> 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
> application.
>
> 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.

Still, it seems like it would be possible to implement this in libgcrypt
without the requirement to modify applications or workarounds.

>> 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.

OK.

>> 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.

OK.

/Simon