Re: Hardening patch

[Kees Cook <kees@debian.org>]

Hi Kurt,

On Sun, Sep 11, 2011 at 02:14:09AM +0200, Kurt Roeckx wrote:
> On Wed, Sep 07, 2011 at 01:46:21PM -0700, Kees Cook wrote:
> > On Wed, Sep 07, 2011 at 10:37:13PM +0200, Guillem Jover wrote:
> > > Also I'm not sure now if this has been brought up before, but the
> > > bindnow option might have noticable startup speed impact depending
> > > on the amount of symbols and shared objects to resolve and load.
> > > The other options seem sane in general.
> > 
> > This is, thankfully, no longer the case now that the linker uses string
> > hashes for symbol resolution. I could not measure a difference in load
> > times (any delta seemed lost in the noise) even for giant (firefox,
> > openoffice.org) applications.
> 
> It was my understanding that for iceweasel the biggest cost of
> starting up is in fact the dynamic linker resolving all the
> relocations.  I currently still see this in libxul.so:
> Relocation section '.rel.dyn' at offset 0x2b480 contains 180767 entries:
> Relocation section '.rel.plt' at offset 0x18c578 contains 2853 entries:
> 
> Not to mention all the other libraries that get linked in.
> 
> Does anybody know if I set bindnow on an executable that it has effect
> on all libraries that get loaded, or only on the directly linked
> libraries?
> 
> Did you try this after a reboot, or was everything already cached?
> 
> What behaviour do you get for shared libraries that have undefined
> symbols?  I assume they'll break?

I did my tests after flushing disk caches.

# echo 3 > /proc/sys/vm/drop_caches
$ LD_DEBUG=statistics MOZ_NO_REMOTE=1 firefox -ProfileManager
...
     12680: 
     12680: runtime linker statistics:
     12680:   total startup time in dynamic loader: 210245310 clock cycles
     12680:         time needed for relocation: 2091312 clock cycles (.9%)
     12680:                  number of relocations: 1283
     12680:       number of relocations from cache: 1000
     12680:         number of relative relocations: 1850
     12680:        time needed to load objects: 207754479 clock cycles (98.8%)
...

# echo 3 > /proc/sys/vm/drop_caches
$ LD_BIND_NOW=1 LD_DEBUG=statistics MOZ_NO_REMOTE=1 firefox -ProfileManager
...
     12716: 
     12716: runtime linker statistics:
     12716:   total startup time in dynamic loader: 200390724 clock cycles
     12716:         time needed for relocation: 2701125 clock cycles (1.3%)
     12716:                  number of relocations: 2095
     12716:       number of relocations from cache: 1000
     12716:         number of relative relocations: 1850
     12716:        time needed to load objects: 197343234 clock cycles (98.4%)
...

so, in this run, the relocation clock cycles are 5% higher with bindnow,
but the total load time is 5% faster. But when I retry it, the deltas in
time are huge between runs. (You can see the bindnow effect on "number of
relocations", which seems to roughly match the counts seen with
LD_DEBUG=bindings.)

If anyone really feels strongly about it, I'm happy to turn off bindnow
by default, but it doesn't seem to be a problem from what I can see in the
testing.

-Kees

-- 
Kees Cook                                            @debian.org