For a JIT I'm working on, I've been trying to call into libc from the emitted code, and I'm running into this.
32-bit x86 Position Independent Code – It's That Bad
11–20 of 104 posts
Re: 32-bit x86 Position Independent Code – It's That Bad
#12So what's the story on 64-bit x64 or other processors?
Re: 32-bit x86 Position Independent Code – It's That Bad
#13There was a time when shared libraries were a necessity. Not to mention supporting myriad architectures. That was a different era. Conditions have changed.
Of course, the designs and implementations have not. They are still in heavy use, 20 years later. What "just works" is never questioned. I am glad to see some people questioning the old assumptions.
Unrelated question: Why does Linux pass arguments in registers instead of using the stack?
Re: 32-bit x86 Position Independent Code – It's That Bad
#14So what's the story on 64-bit x64 or other processors?
Position independent code on x64 is quite trivial, it has a new instruction addressing mode called RIP-relative addressing so that the program can access everything relative to where it is currently executing.
Re: 32-bit x86 Position Independent Code – It's That Bad
#15There was a time when shared libraries were a necessity. Not to mention supporting myriad architectures. That was a different era. Conditions have changed. Of course, the designs and implementations have not. They are still in heavy use, 20 years later. What "just works" is never questioned. I am glad to see some people questioning the old assumptions. Unrelated question: Why does Linux pass arguments in registers in…
What makes you say conditions have changed? Why should I have to wait for everything that consumes OpenSSL downstream to be updated/recompiled to fully patch my system?
Re: 32-bit x86 Position Independent Code – It's That Bad
#16Earlier quoted context omitted.
> 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).
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 s…
Linux had a similar mechanism, "prelink", which also completely broke with ASLR.
Re: 32-bit x86 Position Independent Code – It's That Bad
#17"I know on darwin, we kinda hate those sorts of relocations because they are a performance sap. This type of performance sap is nasty as it is pervasive and invisible and hard to ever get back." -- Mike Stump (gcc-patches ML, 2012)
I think the Solaris linker took some interesting approach with shared libraries at runtime as well.
Re: 32-bit x86 Position Independent Code – It's That Bad
#18There was a time when shared libraries were a necessity. Not to mention supporting myriad architectures. That was a different era. Conditions have changed. Of course, the designs and implementations have not. They are still in heavy use, 20 years later. What "just works" is never questioned. I am glad to see some people questioning the old assumptions. Unrelated question: Why does Linux pass arguments in registers in…
registers are much faster than stack, assuming you immediately make use of them; to use them from the stack you have to load them into registers anyway in most cases
Re: 32-bit x86 Position Independent Code – It's That Bad
#19Earlier quoted context omitted.
As a programmer who unfortunately is suckered into doing devops at times, the more I get to just update the openssl library instead of the whole OS whenever a security flaw in openssl is announced, the more I'm convinced that dynamic linking was very well worth the trouble. Funny how perceptions change depending on the angle you're looking at a problem.
Oddly enough I was thinking about openssl updates specifically. Did you remember to restart all your long-running clients ? (I'm a sysadmin who occasionally gets roped into doing development...) Dynamic linking makes security more difficult to reason about, which is a Bad Thing. It has many pluses, but also many minuses. And with symbol versioning it gets very problematic to actually figure out what your real code pa…
And when you update all your clients with static linked OpenSSL, did you also remember to restart every single one of them? These seem like equivalent problems to me.
Re: 32-bit x86 Position Independent Code – It's That Bad
#20There was a time when shared libraries were a necessity. Not to mention supporting myriad architectures. That was a different era. Conditions have changed. Of course, the designs and implementations have not. They are still in heavy use, 20 years later. What "just works" is never questioned. I am glad to see some people questioning the old assumptions. Unrelated question: Why does Linux pass arguments in registers in…
>Why does Linux pass arguments in registers instead of using the stack?
It's a convention. Depending on your architecture, compiler and API, it uses the stack in a lot of cases (cdecl/stdcall on i386). Linux on AMD64 always uses the SYSV ABI which uses registers as much as possible (i'm assuming for performance reasons, since 'fastcall' does the same on i386).