4 ms·

Tl;dr: dynamic linking results in calling code you didn't mean to. One of many reasons that reliable systems use static linking.

bhawks 6y ago
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.
- StreamBright 6y ago
  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?
- redis_mlc 6y ago
  > Running untested combos of libraries gives me some anxiety. It should, especially with multi-threaded code. (Half of MySQL AB's support calls at one time were user-built binaries. Building things yourself skips the vendor's QA process. For new grads, it used to be a thing of pride to build your own database, web and mail servers on linux, and nobody valued QA at the time.)
- strictfp 6y ago
  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.
- choeger 6y ago
  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.
s_gourichon 6y ago
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
- jcelerier 6y ago
  > 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
flqn 6y ago
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.
- vardump 6y ago
  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...
- mkj 6y ago
  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)
  - DarkmSparks 6y ago
    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.
josteink 6y ago
> 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.
xeromal 6y ago
The article says he used static linking. A dependency of a dependency didn't.

bhawks 6y ago

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.

StreamBright 6y ago
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?
redis_mlc 6y ago
> Running untested combos of libraries gives me some anxiety. It should, especially with multi-threaded code. (Half of MySQL AB's support calls at one time were user-built binaries. Building things yourself skips the vendor's QA process. For new grads, it used to be a thing of pride to build your own database, web and mail servers on linux, and nobody valued QA at the time.)
strictfp 6y ago
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.
choeger 6y ago
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.

s_gourichon 6y ago

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

jcelerier 6y ago
> 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

flqn 6y ago

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.

vardump 6y ago
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...
mkj 6y ago
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)
- DarkmSparks 6y ago
  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.

josteink 6y ago

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

xeromal 6y ago

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