5 ms·

I always wondered why Linux can't just use the same thing as windows for DLLs: Instead of PIC, a big tables of places to patch with the final position. It look

by atesti 12y ago

I always wondered why Linux can't just use the same thing as windows for DLLs: Instead of PIC, a big tables of places to patch with the final position. It looks really terrible to lose one precious register and have all this PIC overhead. I don't use mono's ahead of time compilation because it also creates PIC. The JIT has one register more available. But I haven't measured it yet

JoshTriplett 12y ago
> Instead of PIC, a big tables of places to patch with the final position. Among other things, because that means the text section has to be writeable, and can't have a shared mapping across processes unless it's mapped in the same place in every process, which breaks address-space layout randomization (ASLR).
- atesti 12y ago
  On Windows, one can decide a default position for each DLL and if one is lucky, there is space available in that area of the virtual address space. Otherwise the loader needs to do the relocation work and modify pages and make them writeable temporarily. If multiple processes load the same DLL and the default location happens to be chosen well and there is virtual address space in every process, then the linker can simply share the DLL. That's how I think it was before ASLR came around. I think Windows removes the writeable-flag again after relocating. For the area I described (Mono's JIT vs. Mono's ahead of time compilation as PIC .so-file) I personally don't care that much for ASLR, because it's a managed language and because of specific circumstances of that project.
  - JoshTriplett 12y ago
    Linux had a similar mechanism, "prelink", which also completely broke with ASLR.
- userbinator 12y ago
  Windows has ASLR too (since Vista) and it works with existing DLLs. Only pages which contain relocations can't be shared, which in practice means only code that accesses global data (including calls through the import table to other modules.) All the other pages can be. The whole process image is writable when the loader is running - else how could it load the code into memory? :-) Section attributes are applied after loading.
- yoklov 12y ago
  Off topic, but does anybody know if there's a way to turn off ASLR e.g. while debugging (honestly, i'd be interested if you can do this on any platform)? I'm pretty confident the answer is no, but it can really be a pain sometimes...
  - detaro 12y ago
    /proc/sys/kernel/randomize_va_space on Linux?
  - rwallace 12y ago
    On Windows, the linker has an option to do that.
  - tekacs 12y ago
    Either the linker, or GDB (or your debugger) can disable it for you. Under GDB it's controlled by the setting disable-randomization (defaults to false).
  - zurn 12y ago
    setarch x86_64 --addr-no-randomize myprogram args... (or -R for short)
- dblohm7 12y ago
  Windows doesn't store those thunks in the text section. They're in the .idata section instead.
zurn 12y ago
Linux did this before, but moved to PIC around 1995 as part of the a.out->ELF transition. ELF actually supports (and always did) non-PIC code on x86 Linux in shared libs, ld.so will do fixups to the code on the fly. See http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/ http://eli.thegreenplace.net/2011/11/03/position-independent...
kazinator 12y ago
Windows DLL's don't have features such as the executable overriding symbols in the attached library. In fact, if you call LoadLibrary at runtime, there is no symbol resolution; you have to look up symbols yourself using GetProcAddress. Under dlopen, symbol resolution takes place; it can change the destinations of function calls.
- userbinator 12y ago
  Under dlopen, symbol resolution takes place; it can change the destinations of function calls. I'm probably a bit biased since I'm rather used to Windows' explicit import-export system, but having function calls change just because a library was loaded sounds like an opportunity for some extremely confusing bugs.

by atesti 12y ago

JoshTriplett 12y ago

> Instead of PIC, a big tables of places to patch with the final position. Among other things, because that means the text section has to be writeable, and can't have a shared mapping across processes unless it's mapped in the same place in every process, which breaks address-space layout randomization (ASLR).

atesti 12y ago
On Windows, one can decide a default position for each DLL and if one is lucky, there is space available in that area of the virtual address space. Otherwise the loader needs to do the relocation work and modify pages and make them writeable temporarily. If multiple processes load the same DLL and the default location happens to be chosen well and there is virtual address space in every process, then the linker can simply share the DLL. That's how I think it was before ASLR came around. I think Windows removes the writeable-flag again after relocating. For the area I described (Mono's JIT vs. Mono's ahead of time compilation as PIC .so-file) I personally don't care that much for ASLR, because it's a managed language and because of specific circumstances of that project.
- JoshTriplett 12y ago
  Linux had a similar mechanism, "prelink", which also completely broke with ASLR.
userbinator 12y ago
Windows has ASLR too (since Vista) and it works with existing DLLs. Only pages which contain relocations can't be shared, which in practice means only code that accesses global data (including calls through the import table to other modules.) All the other pages can be. The whole process image is writable when the loader is running - else how could it load the code into memory? :-) Section attributes are applied after loading.
yoklov 12y ago
Off topic, but does anybody know if there's a way to turn off ASLR e.g. while debugging (honestly, i'd be interested if you can do this on any platform)? I'm pretty confident the answer is no, but it can really be a pain sometimes...
- detaro 12y ago
  /proc/sys/kernel/randomize_va_space on Linux?
- rwallace 12y ago
  On Windows, the linker has an option to do that.
- tekacs 12y ago
  Either the linker, or GDB (or your debugger) can disable it for you. Under GDB it's controlled by the setting disable-randomization (defaults to false).
- zurn 12y ago
  setarch x86_64 --addr-no-randomize myprogram args... (or -R for short)
dblohm7 12y ago
Windows doesn't store those thunks in the text section. They're in the .idata section instead.

zurn 12y ago

Linux did this before, but moved to PIC around 1995 as part of the a.out->ELF transition. ELF actually supports (and always did) non-PIC code on x86 Linux in shared libs, ld.so will do fixups to the code on the fly. See http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/ http://eli.thegreenplace.net/2011/11/03/position-independent...

kazinator 12y ago

Windows DLL's don't have features such as the executable overriding symbols in the attached library. In fact, if you call LoadLibrary at runtime, there is no symbol resolution; you have to look up symbols yourself using GetProcAddress. Under dlopen, symbol resolution takes place; it can change the destinations of function calls.

userbinator 12y ago
Under dlopen, symbol resolution takes place; it can change the destinations of function calls. I'm probably a bit biased since I'm rather used to Windows' explicit import-export system, but having function calls change just because a library was loaded sounds like an opportunity for some extremely confusing bugs.