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.)
Say you want to build flying robots 1/64 of an inch in diameter. Do you want 64-bit CPUs?
32-bit x86 Position Independent Code – It's That Bad
81–90 of 104 posts
Re: 32-bit x86 Position Independent Code – It's That Bad
#82Earlier 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...
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).
Re: 32-bit x86 Position Independent Code – It's That Bad
#83Is 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.)
If you want linux to run in places where hardware is less frequently updated, yes.
Re: 32-bit x86 Position Independent Code – It's That Bad
#84There 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?
It's easy to see why sysadmin types like shared libraries, even though that ability is an accidental side-effect of an architecture originally developed as a way to save disk space, but as an end user I strongly prefer isolated applications which depend only on the base OS. Updating one program and thereby inadvertently updating a bunch of other unrelated programs is an anti-feature for me as an end user, because it means I can't trust the state of my system. I don't want to waste time figuring out why things no longer work the way they used to; I want to keep on using my computer for its intended purposes. Therefore I, as an end user, update software as infrequently as possible, and only do so when I don't have anything else I need to do with the computer for the rest of the day, just in case I have to waste a bunch of time figuring out why things don't work anymore.
If I were a sysadmin, and maintaining the computer were my job, this would not be a problem, because figuring out why things don't work and fixing them is what I would be trying to use the computer for; but as an end-user, I just want things to work.
If every application were built with static linking, and system libraries only updated with an explicit system upgrade, I would be much more likely to upgrade frequently, because it would be possible to know and limit the scope of churn implied by any given upgrade act.
Re: 32-bit x86 Position Independent Code – It's That Bad
#85Is 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.)
We still have embedded 8-bit. Expect embedded 32-bit approximately forever.
Embedded 32 bit x86, with the SysV ABI and support for register calling conventions, though?
This is specific to i386, as far as I'm aware. And even then, the worst parts of it are only specific to i386 using the same SysV calling conventions -- ARM has PC relative addressing, as do most other processors commonly used in embedded systems. If you have PC-relative addressing, the entire problem goes away.
Re: 32-bit x86 Position Independent Code – It's That Bad
#86Is 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.)
We still have embedded 8-bit. Expect embedded 32-bit approximately forever.
Yeah, but we all know the embedded 32-bit stuff that's going to be around forever is ARM, not x86.
Re: 32-bit x86 Position Independent Code – It's That Bad
#87I 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).
Windows doesn't store those thunks in the text section. They're in the .idata section instead.
Re: 32-bit x86 Position Independent Code – It's That Bad
#88Is 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.)
Say you want to build flying robots 1/64 of an inch in diameter. Do you want 64-bit CPUs?
No, but you don't want x86 either, at least given anything vaguely resembling today's technology. See, for example, the Michigan Micro-Mote, which is only a few times that size(!) but has ROM and RAM sizes measured in bytes:
http://www.ee.columbia.edu/~mgseok/pdfs/phoenix_isscc_dac_de...
Re: 32-bit x86 Position Independent Code – It's That Bad
#89Earlier quoted context omitted.
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.
IMHO, static linking, be it using a mechanism alike what npm is doing or be it plain-old static linking of binaries also means "you link it, you own it". For every package, you link statically, you as the parent package owner become responsible for all security flaws of all the packages you link statically. And by "responsible" I mean: Every dependent security announcement of a dependent package also becomes your sec…
"And by "responsible" I mean: Every dependent security announcement of a dependent package also becomes your security announcement."
Yes, and no, because as the developer you can look at the security vulnerability and decide if its actually exploitable in your application. That is assuming you can determine it, but in a lot of cases its simple. Especially in a huge library like openSSL. Say for example the only thing i'm using openSSL for is some limited functionality, say SHA256, then I probably can ignore 99.99% of the security issues because they just won't apply.
I've been in this situation with an embedded platform that ships as part of the product I work on. Its pretty much got daily security updates, and yet we rarely get hit by any of them because our usage of the platform is like 1% of its functionality.
Re: 32-bit x86 Position Independent Code – It's That Bad
#90Earlier 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…
Not quite, but you've identified a key leverage point.
You only need to relink the apps, unless the newly patched library breaks its own ABI. Otherwise, it would be ideal for package distributors and package management systems to ship just a single .o file for an app, and do the final linking at package install time. Then updating a buggy static library doesn't require full recompile of any apps.