4 ms·

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

by malkia 15y ago

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

jonoberheide 15y ago
Right, all libaries need to be compiled with -fPIC in order to be randomized. That tends to be much more common than -fPIE.
- aortega 15y ago
  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.
  - jonoberheide 15y ago
    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?
    - aortega 15y ago
      No more CORE for me Doc :) playing the "entrepeneur" now, without the social app or i-phone app, so, no glamour I'm afraid.
  - premchai21 15y ago
    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.
eyemac 15y ago
> 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.

by malkia 15y ago

jonoberheide 15y ago

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

aortega 15y ago
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.
- jonoberheide 15y ago
  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?
  - aortega 15y ago
    No more CORE for me Doc :) playing the "entrepeneur" now, without the social app or i-phone app, so, no glamour I'm afraid.
- premchai21 15y ago
  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.

eyemac 15y ago

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