32-bit x86 Position Independent Code – It's That Bad
1–10 of 104 posts
Re: 32-bit x86 Position Independent Code – It's That Bad
#2The more I play around with musl (the author's C library) the more I'm convinced dynamic linking was not worth the trouble.
Re: 32-bit x86 Position Independent Code – It's That Bad
#3I 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
Re: 32-bit x86 Position Independent Code – It's That Bad
#4I 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
> 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).
Re: 32-bit x86 Position Independent Code – It's That Bad
#5The more I play around with musl (the author's C library) the more I'm convinced dynamic linking was not worth the trouble.
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.
Re: 32-bit x86 Position Independent Code – It's That Bad
#6The more I play around with musl (the author's C library) the more I'm convinced dynamic linking was not worth the trouble.
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.
You are right. Lack of it will be the next wave of security problems
Re: 32-bit x86 Position Independent Code – It's That Bad
#7I 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
> 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 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.
Re: 32-bit x86 Position Independent Code – It's That Bad
#8The more I play around with musl (the author's C library) the more I'm convinced dynamic linking was not worth the trouble.
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 path is to begin with.
Re: 32-bit x86 Position Independent Code – It's That Bad
#9The more I play around with musl (the author's C library) the more I'm convinced dynamic linking was not worth the trouble.
One of the main reasons for dynamic linking has become irrelevant, I believe: the availability of disk and memory space has grown faster than the size of the binary objects.
Re: 32-bit x86 Position Independent Code – It's That Bad
#10The more I play around with musl (the author's C library) the more I'm convinced dynamic linking was not worth the trouble.
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.
It seems you are being downvoted by Go monkeys who drank the static linkage kool-aid.