Dynamic Linking | Hacker News Reader

Dynamic Linking

harmful.cat-v.org

44 pointsbootload55 comments

Dynamic linking is a key innovation that we abandon at our own peril. Only those who are comfortable living in the world dynamic linking creates can agitate for its removal. In a way, advocates of pure static linking are like anti-vaccine advocates.

Here's a killer application of dynamic linking: NSS. It's wonderful to be able to extend applications with new notions of names and addresses.

Remember the bad old days when /etc/passwd parsing was hardcoded and you had a choice of either local users or NIS, and that choice was baked into every application? PAM is another good example.

By the way: there's no such thing as static linking in Windows. All system calls go through ntdll.dll. (In fact, the actual system call numbers are scrambled with every service pack.) This property allows wonderful things, including a pure _userspace_ implementation of 32-bit compatibility for an otherwise pure 64-bit kernel.

In a way, advocates of pure static linking are like anti-vaccine advocates.

Holy fuck, this is one of the most absurd exaggerations I've read in some time. I'm assuming you have a very strong and convincing reason to justify this statement.

Here's a killer application of dynamic linking: NSS.

...

Really? NSS?

OK, so static NIS/YP may not be good at all, but that doesn't change that NSS and the nscd (name server cache daemon) have been amongst the buggiest and most brittle components in glibc, on top of glibc's sequential DNS resolution. It's so bad the Busybox developers had to write a single-threaded fork-based alternative just to deal with its inherent resource exhaustion issues (see the comments in this software: http://busybox.net/~vda/unscd/).

And this: http://www.nico.schottelius.org/blog/nscd-bugs/

musl libc (ever growing in popularity in embedded and other fields for its standards compliance, robustness and implementation simplicity) doesn't support NSS and doesn't intend to, instead researching several alternative methods, the third one probably optimal: http://wiki.musl-libc.org/wiki/Open_Issues#NIS.2FLDAP.2Fothe...

And if you think this problem hasn't been solved so much more elegantly before, look into the details of Plan 9's ndb and factotum.

PAM is another good example.

bsd_auth is much better: http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/...

bsd_auth runs in a subprocess and so can't make persistent modifications to the environment of the caller --- consider pam_limits or pam_env.

> musl libc

I'm conflicted on Musl. I like the idea. I like the focus on robustness. I like Felker's style [1]. But for God's sake, Musl refuses to implement basic operating system primitives we've had for decades, like dlclose(3), all because the author, from his necessarily limited perspective, just can't understand why someone would want those facilities.

I'm sticking with glibc until the Musl people decide they want robustness and feature parity.

By the way: PAM isn't "add in the bloat of additional backends". Dynamic loading of backends is the opposite of bloat.

There's absolutely no reason Felker can't greatly improve libc robustness and maintain at least source-level compatibility with a libc we've used for decades and that has many valuable features. Musl's sin is being gratuitously opinionated.

[1] http://ewontfix.com/, good for the most part. Wrong about 32-bit PIC being terrible. (What we really need is -fvisibility=hidden and -Bsymbolic by default.)

robustness and feature parity

Some features aren't worth having parity with, or at least need to be well rethought - and Felker has had a good track record with the latter in terms of thread-local storage, UTF-8 and other properties, so I'm looking forward to how the musl community settles the question of name directories.

Source level compatibility with glibc is a terrible idea, it is a huge and bloated system, which quite clearly has made a lot of mistakes - which it is gradually fixing some of. C is no longer a general purpose programming language, and needs to be used more carefully when it is needed, and Musl helps you do that. Use a safe language if you want more stuff.

Puritanism in system libraries helps nobody. What you consider "bloated" others consider essential. If you're responsible for the lowest-level userspace library on a system, one that every component uses to talk to every other component, you have no business foisting your opinion on the world.

glibc, buggy and hacky as it is, doesn't try to impose its opinions on you.

Source level compatibility means replicating the bugs, which is pointless, just use glibc if you want it to be identical. Musl is basically like the libcs of the BSDs, ie less stuff it just made up, just the standards compliant stuff. Add the other stuff to your own library.

> Source level compatibility means replicating the bug

No it doesn't. For example: we can fix the the glibc pthread_mutex_lock bug without affecting ABI or source compatibility.

Bugginess of one particular implementation (and let's be fair here -- most of the stuff in glibc is quite ugly and hacky, a direct consequence of the bazaar model) has nothing to do with dynamic linking. Both PAM and NSS have been used successfully in a dozen of other operating systems for decades, and that's dynamic linking that facilitated these technologies.

Are you arguing that glibc code quality will magically go up if they abandon dynamic linking?

I wasn't arguing against dynamic linking, but the parent poster's fervor at attacking its critics, and their poor example of a supposedly great thing it facilitated.

I'm not sure if you can blame glibc on bazaar practices. musl and glibc both have similar, BFDL-driven development models (well, glibc did until Drepper got booted, at least) yet musl has far better curation and attentiveness than glibc.

PAM and NSS have always been controversial (though PAM particularly) and better ways have been both developed and proposed.

When Heartbleed hit, to fix your dynamically linked system, you replaced openssl and called it a day.

With your statically linked system, you replace every single binary on your system that linked to openssl during build (if you can figure that out).

With heartbleed I ran apt-get update && apt-get upgrade. With static linking I do the same. (I don't consider forcing the Debian build farm to rebuild dependencies an insurmountable challenge).

And all the programs you compiled from source or got from other parties? Rebuilding the world on a whim is fantasy.

I disagree. Rebuilding the world on a whim is devops.

You know, some of us don't do webdev.

webdev != devops

I am yet to see devops at any of our customers.

The security argument goes both ways though. Lets say I update my music player and through some complicated chain it ends up also updating my system libc and openssl, and lets say one of those libraries accidentally introduced a vulnerability. If those libraries were statically linked, it's just my music player that's in trouble. With dynamic linking, instead of my music player having a security issue (not a big deal, probably), my entire system is now vulnerable including my web browser, even though I didn't update my web browser. (much bigger deal)

If you consider biological ecosystems, diverse genetics are almost always more robust against infection. You could potentially make that analogy about the ecosystem of computers as well.

In your situation, static building would also result in rebuilding libc and openssl, and from there your web browser, as most package management systems, and package managers, would make sure that the updated libc were relinked in to as many programs as possible as soon as they were available.

Most systems are actually a mix of statically linked and dynamically linked executables.

For example, the systems I compile can all boot and function without the need for a dynamic linker. These static binaries are on a root filesystem that is in memory, not disk. Hence I can boot from removable media and then remove the media so the slot is open.

If I need larger, complex, dynamically linked programs I mount a filesystem that has them along with the dynamic linker and then chroot. I build these filesystems separately, usually storing them on removable media.

I think it all depends on the granularity of dependencies and how you cope with multiple versions. If every app have their own version of a lib, you get problems with security updates and bloat. If you force a single version of each lib, you get a really slow testing and itegration cycle. If you choose something in between those extremes I think dynamic linking does have merit.

I'll take an "insecure" ldd over having to recompile every single binary when there is a glibc/libjpeg/libpng/libwhatever security fix, any day.

I'm sure the ldd problem could be solved by writing a slightly smarter "ldd" that doesn't actually execute the ELF binary, as well.

Try readelf -d.

    $ readelf -d ~/edev/trunk/src/emacs | grep NEEDED
     0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libtiff.so.5]
     0x0000000000000001 (NEEDED)             Shared library: [libjpeg.so.8]
     0x0000000000000001 (NEEDED)             Shared library: [libpng12.so.0]
     0x0000000000000001 (NEEDED)             Shared library: [libgif.so.4]
     0x0000000000000001 (NEEDED)             Shared library: [libXpm.so.4]
     0x0000000000000001 (NEEDED)             Shared library: [libgtk-3.so.0]
     0x0000000000000001 (NEEDED)             Shared library: [libgdk-3.so.0]
     0x0000000000000001 (NEEDED)             Shared library: [libpango-1.0.so.0]
     0x0000000000000001 (NEEDED)             Shared library: [libcairo.so.2]
     0x0000000000000001 (NEEDED)             Shared library: [libgdk_pixbuf-2.0.so.0]
     0x0000000000000001 (NEEDED)             Shared library: [libgio-2.0.so.0]
     0x0000000000000001 (NEEDED)             Shared library: [libgobject-2.0.so.0]
     0x0000000000000001 (NEEDED)             Shared library: [libglib-2.0.so.0]
     0x0000000000000001 (NEEDED)             Shared library: [libSM.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libICE.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libXrender.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [libXft.so.2]
     0x0000000000000001 (NEEDED)             Shared library: [libasound.so.2]
     0x0000000000000001 (NEEDED)             Shared library: [librsvg-2.so.2]
     0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libacl.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [libdbus-1.so.3]
     0x0000000000000001 (NEEDED)             Shared library: [libXfixes.so.3]
     0x0000000000000001 (NEEDED)             Shared library: [libxml2.so.2]
     0x0000000000000001 (NEEDED)             Shared library: [libgpm.so.2]
     0x0000000000000001 (NEEDED)             Shared library: [libtinfo.so.5]
     0x0000000000000001 (NEEDED)             Shared library: [libgconf-2.so.4]
     0x0000000000000001 (NEEDED)             Shared library: [libselinux.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [libfreetype.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libfontconfig.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [libotf.so.0]
     0x0000000000000001 (NEEDED)             Shared library: [libm17n-core.so.0]
     0x0000000000000001 (NEEDED)             Shared library: [libm17n-flt.so.0]
     0x0000000000000001 (NEEDED)             Shared library: [libgnutls-deb0.so.28]

Dynamic linking ends up being a wash or a net negative for # of recompiles when you consider that developers of important dynamic libraries break binary compatibility all the time on non-security-related changes.

> developers of important dynamic libraries like glibc break binary compatibility all the time on non-security-related changes.

You couldn't have picked a worse example. glibc goes to great lengths to maintain backward compatibility. glibc is practically the reason ELF symbol versions exist.

https://www.redhat.com/f/summitfiles/presentation/June2/Deve...

Guess I was wrong about glibc, so I removed that from the comment. I seem to remember fairly frequent full system updates, with it as the center, when I used Linux, but it might have been another library at fault.

And yet in practice, the number of steam games on linux that I can't run because the developers compiled them against a newer version of libc than I have is in the dozens.

Compatibility works the other way around. You can run binaries compiled against an older libc on a newer glibc, but there's no reason to expect that binaries compiled against a newer libc should be able to run against older versions of libc. If you demand that, you demand software stasis.

It's a libc implementation for christ's sake. If ever a library should remain in stasis, it would be a libc implementation.

There's a clue in your formulation that guides you to the right answer - no useful library should ever remain in stasis.

Or as it's generally said, the only software that never changes is software no one uses.

That's just, like, your opinion, man; tell it to the retrocomputing folks.

IMHO, the reluctance to "finish" a project and the stigma against something being "in maintenance mode" is responsible for most of the bloat and messes in modern software. Perhaps it's related to "CADT": http://www.jwz.org/doc/cadt.html

It's also, ironically, the cause of numerous security flaws. Maybe we wouldn't have to worry so much about security flaws in our libraries if we weren't constantly tearing them down and remaking them.

Regardless, in the case of libc, I genuinely cannot think of a reason to break binary compatibility, backwards or forward. The POSIX standard is set in stone, the interfaces are stable, the data types are opaque, etc. Of course you can create new implementations of memcpy etc that take advantage of new instruction sets, but I don't see why you need to break binary compatibility to do so.

> in the case of libc, I genuinely cannot think of a reason to break binary compatibility, backwards or forward

Well, since you can't think of one, there must not be one.

Symbol versioning came from Solaris, originally, and the actual de-facto standard was specified by Sun.

Even if you were right about the bc breaks, I think it's still better to apply a security patch to a stable version of glibc and just deploy that, instead of ensuring every ELF file on the system is updated.

> ensuring every ELF file on the system is updated.

You're right. Keep in mind, though, that we're living in a world where people ship applications built with dependencies like this:

  deps = http://some.random.server.ru/some-library:1.4.4

and installation software like this:

  curl http://lol.hackme.cn | sudo bash

Do you expect people to really understand the nuances of security updates?

I do expect them to understand that, when they are arguing against it. :)

I agree, and I think this approach works very well on Windows, where Microsoft has a serious commitment to backwards compatibility at any cost. But in my experience, there wasn't anywhere near the same level of appreciation for binary compatibility in the Linux userland (though Torvalds clearly cares about this in the kernel).

Sure, leave it up to the developers of each application to stay on top of the security updates for each library they bundle. Fantastic idea.

I say you leave it up to the distribution (Red Hat, Ubuntu).

Chill out. I didn't say dynamic linking was "good" or "bad," or that it isn't right to put security first, just that this isn't as great of a benefit as it appears to be if library devs aren't careful to preserve binary compatibility (which most, in my experience, aren't).

> I'll take an "insecure" ldd over having to recompile every single binary when there is a glibc/libjpeg/libpng/libwhatever security fix, any day.

With the "independent packaging" push using containers and dependency bundling, you get both downsides for the cost of one.

https://blogs.gnome.org/alexl/2015/02/17/first-fully-sandbox...

What exactly is being proposed here? Would every app statically link against some version of UIKit or the Android Java libs? How would the app run on different versions of the OS? How do you maintain forward compatibility?

It's mystifying that the debate here centers around performance or RAM usage. The benefit of dynamic linking is architectural: it enables different components to evolve independently.

I understand Plan 9 has an unusual approach, where things that are traditionally library calls (getMousePosition) are instead filesystem operations (read /dev/mouse). But this seems terribly rigid to me: we've just replaced structs with a static byte stream format. How do you evolve this?

The interesting bit is that Limbo on Inferno, Plan9's successor, only uses dynamic linking.

No, dynamic linking isn't "harmful."

Take it to its logical conclusion - statically compile the kernel in each executable. Build the task scheduler in the CPU. Make every program run on pure bare metal.

Isn't this docker / etc in a nutshell?

Albeit running on a VM as opposed to bare metal, and not actually currently statically linking everything.

Then watch the world burn at the CPU level :).

http://www.techrepublic.com/article/unikernels-offer-a-strip...

https://news.ycombinator.com/item?id=8606968

Mirage OS, you mean?

It seems like we're trying to head that way.

Reply on news.ycombinator.com