[gnutls-devel] Automatic library initialization

[Tim Rühsen]

Am Montag, 16. November 2015, 10:45:19 schrieb Andy Lutomirski:
> On Mon, Nov 16, 2015 at 10:37 AM, Tim Rühsen <tim.ruehsen at gmx.de> wrote:
> > Am Montag, 16. November 2015, 19:10:02 schrieb Andrew W. Nosenko:
> >> On Mon, Nov 16, 2015 at 6:24 PM, Nikos Mavrogiannopoulos
> >> <nmav at gnutls.org>
> >> 
> >> wrote:
> >> > On Mon, Nov 16, 2015 at 4:54 PM, Tim Ruehsen <tim.ruehsen at gmx.de> 
wrote:
> >> > >> Something like the following. Have each program not wishing to use
> >> > >> global initialization to define a symbol which overrides a weak one
> >> > >> from gnutls. In practice that would mean setting:
> >> > >> GNUTLS_SKIP_GLOBAL_INIT
> >> > >> in some global section in your program. That can also be easily
> >> > >> backported in 3.3.x and you can check for that feature with an
> >> > >> ifdef.
> >> > >> Would that be acceptable?
> >> > > 
> >> > > Brilliant idea. I'll use it for my projects... but other projects
> >> > > won't
> >> > > benefit immediately (they first have to know).
> >> > 
> >> > I'll then include it in 3.4.x and 3.3.x releases.
> >> 
> >> First at all, IMHO, _current_ API, which eliminates requirement to call
> >> explicitly some init function is a good.  And the "old-style API" with
> >> requirement to call some init function before any thread and/or child
> >> processes will be forked, which you want to resurrect, is a bad.
> >> 
> >> Very simple example: DSO uses some library, which have requirement to
> >> global init.  DSO loaded on demand.  How you meet this "global init
> >> before
> >> any thread forked" requirement?
> > 
> > I already wrote some words regarding this scenario earlier in this thread.
> > Please re-read.
> > 
> > Despite that, Nikos found a solution that doesn't touch current behavior.
> > 
> > Tim
> 
> What exactly does gnutls do during initialization that takes this much
> time?  Could it be made to generate whatever tables it needs at
> compile time?
> 
> (I guess it needs to self-tests, but that should only apply in FIPS
> mode, which shouldn't be the default.)

You can have a look at code in lib/gnutls_global.c (branch gnutls_3_3_x).

To see what function calls takes how many cycles, I use (on Debian SID, KDE):
$ valgrind --tool=callgrind wget
$ kcachegrind callgrind.out.xxxxx

Shows ~16.000.000 cycles.

Most (65%) of the time goes into _gnutls_rnd_init() which calls 
wrap_nettle_rnd_init().
But please check this yourself.

What I currently don't understand is why currently so many cycles go into 
_dl_start() and the like (relocation, symbol lookups) - ~4.000.000 cycles. 
This has been much less a few months ago... looks like immediate binding, but 
'hardening-check' says no. Something has changed in Debian - looks like all 
symbols are relocated directly at startup, currently.

Regards, Tim