
32-bit x86 Position Independent Code – It's That Bad - cremno
http://ewontfix.com/18/
======
atesti
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

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

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

~~~
tekacs
Either the linker, or GDB (or your debugger) can disable it for you. Under GDB
it's controlled by the setting disable-randomization (defaults to false).

------
bandrami
The more I play around with musl (the author's C library) the more I'm
convinced dynamic linking was not worth the trouble.

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

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

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

~~~
deathanatos
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 package manager keeps track…)

~~~
danieldk
Tip for Debian/Ubuntu users: checkrestart from the debian-goodies package is a
nice wrapper around lsof that lists running binaries that rely on outdated
solibs:

[http://manpages.debian.org/cgi-
bin/man.cgi?query=checkrestar...](http://manpages.debian.org/cgi-
bin/man.cgi?query=checkrestart)

[https://gehrcke.de/2014/06/good-to-know-checkrestart-from-
de...](https://gehrcke.de/2014/06/good-to-know-checkrestart-from-debian-
goodies/)

It not only shows processes that run older solibs, but in the case of
services, it will also give you the commands to restart them :).

~~~
tankenmate
It also shows programs that are still using the old binary that has been
deleted (unlinked from the filesystem) but not refcount 0 freed. This can also
be used to uncover some forms of hiding that hack attempts use.

------
dottrap
So what's the story on 64-bit x64 or other processors?

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

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

~~~
davidgerard
We still have embedded 8-bit. Expect embedded 32-bit approximately forever.

~~~
wtallis
Yeah, but we all know the embedded 32-bit stuff that's going to be around
forever is ARM, not x86.

~~~
creshal
We _hope_ it's not going to be x86… I dunno. I still see too many embedded
486/686 clones around for my liking, and Intel is now trying to get into the
whole IoT business with x86-32 Quark CPUs.

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

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

------
gwu78
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 instead of
using the stack?

~~~
deafeningblow
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?

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

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

~~~
gwu78
Is this supposed to be an answer?

I like marssaxman's comment.

I'm not sure I would call this a "feature" because I think of "features" as
being intentional and if marssaxman is correct, this justification for shared
library use was an accidental side effect.

But I have limited knowledge of the history behind dynamic linking. Hence my
questions. I am just curious.

------
amelius
> Obviously what we'd like to see is: "foo: jmp bar"

Shouldn't that be "foo: call bar"?

~~~
JasuM
I think it's JMP due to tail-call optimization. If there's a JMP, the RET of
the inner function (bar) returns from the outer one (foo) also, and one
unnecessary jump is eliminated.

