Hacker News Reader

Comment by malkia | Hacker News Reader

So how does the ASLR work with images optimized to be loaded at specific address? (-fPIC all of them?)

I was under the impression that if you have two or more instances of the same .so/.dll/.dylibs in different processes, and they end up using different virtual addresses then they can't share the same code page. Maybe I'm behind times...

View on HN

> I was under the impression that if you have two or more instances of the same .so/.dll/.dylibs in different processes, and they end up using different virtual addresses then they can't share the same code page. Maybe I'm behind times...

By design, dylibs (i.e. shared dynamic libraries) are allowed to be loaded at different virtual addresses and still have their text/ro sections shared.

Because dylibs are always compiled with -fPIC, they do not have any dependence on their load addresses (branches are pc-relative, data loads go through the GOT, etc). This allows the dyld to map the physical address(es) of a dylib's text/ro section(s) into virtual address spaces of multiple processes with very little relocation.

Right, all libaries need to be compiled with -fPIC in order to be randomized. That tends to be much more common than -fPIE.

I disagree with -fPIE making things slow, specially in the ~13 general purpose registers of ARM. Maybe -fPIE affect things in the register-starved x86, not so much in modern archs. Also, "fucked up beyond all repair" is a little exagerated when the repair is to add "-fPIE" to some binaries.

As a mild counterpoint, I semi-recently tried to start habitually compiling my executables with -fPIE on my AMD64 development machines, and at least several months ago, the GDB I got from Debian sid was not up to the task of debugging such a creature and would fail to attach to the process and emit mysterious error messages. AMD64 being a mature architecture where I would expect PIE to have a significant benefit, it wouldn't surprise me if this were true for ARM also, or if other toolchain elements had similar problems. So that could provide a disincentive to switch over to position-independent executables.

Yeah, I'm guessing ARM will be ok with respect to GPRs (although I certainly haven't done any benchmarks).

Dug's FUBAR comment was just an attempt cram in as many acronyms as possible...of course the situation is improvable. ;-)

Still at CORE these days?

No more CORE for me Doc :) playing the "entrepeneur" now, without the social app or i-phone app, so, no glamour I'm afraid.

Reply on news.ycombinator.com