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

61–70 of 104 posts

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

#61

Post by FreezerburnV »

_yosefk wrote: post #52
zzzcpan wrote: post #50

Earlier quoted context omitted.

There are no problems with updates anymore. You don't have to download everything to update a bunch of static binaries. There are things, like bsdiff, that allow you to download and patch only tiny differences related to a security flaw. There is no need for dynamic linking for updates. Really.

What if you have binaries compiled from proprietary code bases from umpteen vendors using different compilers and compiler options and what-not, and they all use the Internet for self-updating and stuff and they all need to be patched? How are you going to do that? Also - weakly related - what if you want to use a plugin from vendor A inside the program of vendor B, and they live in the same address space - how are y…

Chances are, if you're using those binaries, they have their own versions of whatever libraries they depend on already baked into themselves somehow. So even if they depend on OpenSSL, and you update OpenSSL on your system, they're probably still going to end up using a version from a year ago regardless of what you do.

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

#62

Post by detaro »

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

/proc/sys/kernel/randomize_va_space on Linux?

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

#63

Post by GFK_of_xmaspast »

wtbob wrote: post #55
_yosefk wrote: post #52

Earlier quoted context omitted.

What if you have binaries compiled from proprietary code bases from umpteen vendors using different compilers and compiler options and what-not, and they all use the Internet for self-updating and stuff and they all need to be patched? How are you going to do that? Also - weakly related - what if you want to use a plugin from vendor A inside the program of vendor B, and they live in the same address space - how are y…

> What if you have binaries compiled from proprietary code bases… Then don't do that. Seriously, RMS, ESR and others have written a plethora of well-reasoned essays indicating why proprietary software is a poor choice.

ESR advocating for something is reason enough to seriously consider the alternative.

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

#64

Post by nimrody »

bandrami wrote: post #8
pilif wrote: post #5

Earlier 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…

Should be relatively easy to make a tool that uses `losf` or similar to get a list of all running processes that depend on a shared library.

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

#65

Post by eropple »

wtbob wrote: post #55
_yosefk wrote: post #52

Earlier quoted context omitted.

What if you have binaries compiled from proprietary code bases from umpteen vendors using different compilers and compiler options and what-not, and they all use the Internet for self-updating and stuff and they all need to be patched? How are you going to do that? Also - weakly related - what if you want to use a plugin from vendor A inside the program of vendor B, and they live in the same address space - how are y…

> What if you have binaries compiled from proprietary code bases… Then don't do that. Seriously, RMS, ESR and others have written a plethora of well-reasoned essays indicating why proprietary software is a poor choice.

So you're admitting that this isn't a solution and you need to change the rules of the game to make it work.

Well, I'm convinced.

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

#66

Post by JoachimSchipper »

wtbob wrote: post #56
pjc50 wrote: post #29

Earlier quoted context omitted.

Dynamic linking is required for anything resembling a plugin architecture (such as PAM).

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.

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

#67

Post by kryptiskt »

_yosefk wrote: post #52
zzzcpan wrote: post #50

Earlier quoted context omitted.

There are no problems with updates anymore. You don't have to download everything to update a bunch of static binaries. There are things, like bsdiff, that allow you to download and patch only tiny differences related to a security flaw. There is no need for dynamic linking for updates. Really.

What if you have binaries compiled from proprietary code bases from umpteen vendors using different compilers and compiler options and what-not, and they all use the Internet for self-updating and stuff and they all need to be patched? How are you going to do that? Also - weakly related - what if you want to use a plugin from vendor A inside the program of vendor B, and they live in the same address space - how are y…

> What if you have binaries compiled from proprietary code bases from umpteen vendors using different compilers and compiler options and what-not, and they all use the Internet for self-updating and stuff and they all need to be patched? How are you going to do that?

The proprietary code isn't going to chance using system libs beyond libc, because of portability. So they likely still need to be patched separately.

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

#68

Post by pmahoney »

deathanatos wrote: post #22
yuriks wrote: post #19

Earlier quoted context omitted.

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.

Not quite, I think. With a .so, I can ask `lsof` which services on the machine require restart: the ones that haven't are linked to a deleted so. And you wouldn't need to restart the clients with static OpenSSL — you need to recompile them . And with static linking, I'm not sure how you would easily determine the linked version out to say, the minor or the micro. (Perhaps, if this is your OS's thing like nix, the pac…

I don't think that nix would be able to tell you which version of OpenSSL some binary linked statically, as there would no longer be a reference from that binary to /nix/store/xxx-openssl-1.0/lib/libssl.so.

Nix generally uses dynamic linking, though the links are to absolute paths to a specific library version, so upgrading OpenSSL requires a recompile much like with static linking.

With "normal" dynamic linking, upgrading OpenSSL and restarting some service means you're now running untested code, hoping that the new version of the dynamic lib really doesn't change an interface on which your code depends. But to be fair, this is usually a good assumption.

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

#69

Post by kazinator »

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.

Post reply on HN