[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hardening patch

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

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


Kees Cook                                            @debian.org

Reply to: