Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

32-bit x86 Position Independent Code – It's That Bad

ewontfix.com

Post reply on HN
Print view View original

71–80 of 104 posts

Re: 32-bit x86 Position Independent Code – It's That Bad

#71

Post by gwu78 »

mappu wrote: post #20
gwu78 wrote: post #13

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

"It's a convention."

Does Minix use that convention? How about BSD?

Re: 32-bit x86 Position Independent Code – It's That Bad

#72

Post by userbinator »

kazinator wrote: post #69
atesti wrote: post #3

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

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.

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.

Re: 32-bit x86 Position Independent Code – It's That Bad

#73

Post by gwu78 »

deafeningblow wrote: post #15
gwu78 wrote: post #13

There 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?

Are you suggesting that the original purpose of shared libraries relates to patching software?

Others seem to be suggesting that the emergence of dynamic linking was a response to general limitations in secondary storage and memory. Limitations that no longer exist.

Re: 32-bit x86 Position Independent Code – It's That Bad

#74

Post by icebraining »

gwu78 wrote: post #71
mappu wrote: post #20

Earlier quoted context omitted.

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

"It's a convention." Does Minix use that convention? How about BSD?

"The calling convention of the System V AMD64 ABI is followed on Solaris, Linux, FreeBSD, Mac OS X, and other UNIX-like or POSIX-compliant operating systems."

http://en.wikipedia.org/wiki/X86_calling_conventions#System_...

Re: 32-bit x86 Position Independent Code – It's That Bad

#75

Post by creshal »

bla2 wrote: post #70

Is 32-bit Linux still worth worrying about? It seems that 64-bit CPUs and kernels have been around for a really long time now. (Honest question.)

Intel is still selling (well, trying to…) 32-bit only Atom/Quark CPUs for smartphones and IoT devices.

Coincidentally, Android defaults to PIC in newer SDK versions. So there is still a pressure to optimize for IA32+PIC.

Re: 32-bit x86 Position Independent Code – It's That Bad

#76

Post by icebraining »

gwu78 wrote: post #73
deafeningblow wrote: post #15

Earlier quoted context omitted.

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?

Are you suggesting that the original purpose of shared libraries relates to patching software? Others seem to be suggesting that the emergence of dynamic linking was a response to general limitations in secondary storage and memory. Limitations that no longer exist.

Does it have to be the original purpose to be a useful feature?

Re: 32-bit x86 Position Independent Code – It's That Bad

#78

Post by rwallace »

yoklov wrote: post #60
JoshTriplett wrote: post #4

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

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

On Windows, the linker has an option to do that.

Re: 32-bit x86 Position Independent Code – It's That Bad

#79

Post by derekp7 »

pilif wrote: post #5
bandrami wrote: post #2

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

I personally would like to see a distribution have a mixed policy -- dynamic linking against core libraries that are part of the default / basic OS install, and static linking against low usage libraries. That way, you keep the "update one library package to fix a bunch of programs", yet you also reduce cross dependency issues by limiting the number of library packages a given program is dependant on.

Re: 32-bit x86 Position Independent Code – It's That Bad

#80

Post by bandrami »

JoachimSchipper wrote: post #66
wtbob wrote: post #56

Earlier quoted context omitted.

Not really—one could use processes and some form of IPC (shared memory, pipes, whatever). The efficiency could be pretty bad, but the safety and reliability could be better.

In fact, OpenBSD delegates logins to a login_ binary, e.g. http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/... . That works. OpenBSD's system is not as flexible as PAM, with the attendant upsides and downsides.

Yeah. There's a reason I stick with OpenBSD.

I have absolutely no need for my authentication system to be "flexible".

Post reply on HN