OSDev.org

What are pros and cons of them?
Some other shared libraries approaches?

runtime relocations?

I presume you're talking about the two philosophies used by ELF and PE. In short, Position independent code can be slightly slower to execute than statically linked code, but is faster to load and can always be shared between processes. On the flip side, runtime relocations (PE-style) mean that if the address chosen at compile time is unavailable, very expensive relocations need to be done (taking up time and memory), these also require far more relocation entries than PIC.

Nowdays, PIC is probably the best, as modern CPUs have pretty good PC-relative addressing and the like, but back in protected mode, static linking was quite a bit faster.

While x86-64, ARM, etc. have improved the PIC situation with the addition of RIP-relative addressing, PC-relative instructions, etc., respectively, the most efficient solution in terms of performance is to forget about shared objects and only use position-dependent code. The trade-off is pretty good considering the fact that data typically takes up a lot more memory.

However, if you do want shared objects, PIC is the recommended way to go as otherwise the text segment would require runtime modifications (leading to memory and performance overheads, since we're talking about a read-only segment) that would ironically result in it becoming non-sharable. On the other hand, PIC uses indirections via tables like the GOT and the PLT, which reside in the data segment.

Patching relocations in absence of single-address-space memory has a drawback that no library code could be shared between two processes; unless they are loaded at fixed virtual addresses.

I'm going to also bring up that position independent code might be a little more practical to use in lower level environments (ie. kernel modules, etc.).
At least, that's the case in my experience.

For example, it's quite easy to relocate ELF files in memory to whatever address modules are loaded to.
(Potentially that being wherever it is that the boot loader put them, although that might cause issues later.)
They don't need much more than a simple move in memory, symbol address adjustment, bit of linking and perhaps a couple of page mappings.

Thanks all for info. Are there some Cons of PE approach?

Love4Boobies wrote:While x86-64, ARM, etc. have improved the PIC situation with the addition of RIP-relative addressing, PC-relative instructions, etc., respectively, the most efficient solution in terms of performance is to forget about shared objects and only use position-dependent code. The trade-off is pretty good considering the fact that data typically takes up a lot more memory.

Theres a good security argument (defense in depth) that code at fixed addresses should be deprecated, as it makes stack smashing attacks (and similar) significantly easier and more effective (particularly in combination with e.g. return-to-libc attacks). Not only does it mean that all functions are at fixed addresses, it means that the locations of the R/W data pages are fixed also (which may make attacks easier or harder, depending upon how difficult it is for the attacker to invoke e.g. mprotect)

(Another good argument for shared libraries is, of course, in ensuring that all library code is kept up to date)

I said it bad I wanted good things about windows approach?

lopidas wrote:good things about windows approach?

In that formulation, a religious "no", perhaps?

Relocatable or fixed position code is significantly faster (~10%) on 32-bit x86 at runtime. On 64-bit, that difference is neglegible. Security can still be fixed using ASLR, but memory overhead and load times are potentially an order of magnitude worse.

Personally, I feel the fault lies with programming languages or implementations thereof. The OS shouldn't try to protect vulnerable code from itself. With safe languages and/or language implementations, the code would avoid vulnerabilities like buffer overflows altogether instead of obfuscating them.

Love4Boobies wrote:Personally, I feel the fault lies with programming languages or implementations thereof. The OS shouldn't try to protect vulnerable code from itself. With safe languages and/or language implementations, the code would avoid vulnerabilities like buffer overflows altogether instead of obfuscating them.

There is a lot to be said for defense in depth. ASLR is a mitigation factor for buffer overflows. Obviously this doesn't obviate the issue of the buffer overflow, just reduces the exploitability of it.

Every line of defense you use is one additional hurdle your attacker has to jump over... and maybe, just maybe, the difference between a DOS and a privilege escalation. Or, if nothing else, the difference between a zero-day exploit and getting the patch out before the exploit is in the wild.

lopidas wrote:I said it bad I wanted good things about windows approach?

I thought the advantages and disadvantages of both formats were summarized fairly well in this thread. Here is the same summary in simpler terms:

In a nutshell, PE DLL's may have larger loading overhead and sharing them is not guaranteed; all due to rebasing. However, you may precalculate the base so as to drastically decrease the probability of rebasing being required in the first place. There is a catch, though: For this to work, you must give up ASLR, whose point is to reduce the likelihood of certain vulnerabilities (i.e., some buffer overflows) being exploited.

On the other hand, PIC with ELF shared objects is somewhat slower to run, albeit libraries are sometimes noticeably faster to load. Furthermore, sharing between different processes is always possible, even with ASLR.

Whether or not you design your loader to do ASLR is entirely up to you; as you can see, different people have different opinions on this.

Thanks, nice for nice summary.