[gnutls-devel] Automatic library initialization

[Andrew W. Nosenko]

On Mon, Nov 16, 2015 at 10:14 PM, Tim Rühsen <tim.ruehsen at gmx.de> wrote:

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

Just a side note: it would be interesting to verify valgrind's results by
something like DTrace/SystemTap...  I.e. by something that probes running
system instead of simulated environment.

About relocation: some sort of ASLR?

-- 
Andrew W. Nosenko <andrew.w.nosenko at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20151116/489f7197/attachment.html>