Hacker News Reader

Comment by jeffrallen | Hacker News Reader

Tl;dr: dynamic linking results in calling code you didn't mean to.

One of many reasons that reliable systems use static linking.

Is it really needed to go as far as ditching dynamic linking and its benefits? Export only symbols intended to be called from outside, with a prefix, problem solved.

From TFA:

> This is a great opportunity to remind everyone: don’t use generic function names like this in your shared libraries, at least not in your exported symbols! You could easily run into a situation similar to this one. In my opinion, prefixes are definitely a good idea for your library’s exported symbols. In this case, both libusbmuxd and Samba were breaking that guideline.

> (...) dynamic libraries on Linux export all symbols by default unless you specify otherwise.

> libusbmuxd already fixed this on their end quite a while ago — they now only export functions intended to be public, which have a usbmuxd_ or libusbmuxd_ prefix

> Export only symbols intended to be called from outside, with a prefix, problem solved.

any solution that depends on the goodwill of a third party is a 100% no-go

A common argument around dynamic linking is that it makes security updates easier.

This seems like a weak argument as an update could easily introduce new bugs with a security impact as well. Static linking gives a tested, known good executable. Running untested combos of libraries gives me some anxiety.

It's not really about static vs. dynamic linking IMO. The point with ld is that the distribution has one central point for linking. If static linking with go, rust, C, etc. would work in a similar fashion, each executable could be shipped with a "re-link" script and the distribution could again provide security patches efficiently.

But when linking happens in some poorly maintained script, inside a custom build systen, written in two or more languages, running inside a docker container, executed by some year-old CI integration, patching security issues becomes impossible.

The argument is made on a system level, not on a single binary level.

Given many dynamically linked binaries, it's relatively easy to patch say OpenSSL on a system.

If all binaries are statically linked, you need to relink all binaries and push new versions of each one.

I think it is very hard to quantify problem. In my experience once you have a security policy about updates it is equally easy to update statically and dynamically linked software. The real problem is that most companies do not care. On the other hand, if many application are running in Docker today does it matter if that app has static or dynamic linking?

The article says he used static linking. A dependency of a dependency didn't.

I don't think static linking saves you here. This looks to be caused by an ODR violation (the "one definition rule"). The linker has two symbols with the same identifier and has to choose one.

Static linking would error out with something like

  bar.c:(.text+0x0): multiple definition of `socket_send'

at compile time. (edit: I mean static linking everything including third party libraries)

it was statically linked.

the issue was caused by another dynamically linked library referencing a different library at run time on a different linux distro than it was built on.

even says as much in the article.

Perhaps this should trigger a warning. Or even an error with an option to provide (or generate with a known good configuration) an exclusion list for those.

Yeah, there are probably a lot of ways this would still cause issues. In any larger project with non-trivial dependencies, C-ABI generates a lot of extra work. At least without decorated (= mangled) function names...

> Tl;dr: dynamic linking results in calling code you didn't mean to.

Way to show you didn't read the linked article. Because in it he even mentions he used static linking.

So that alone won't always save you.

Reply on news.ycombinator.com