Multiple bugs in dlopen & dependency tracking

Multiple bugs in dlopen & dependency tracking

[Rich Felker]

Commit 4ff234f6cba96403b5de6d29d48a59fd73252040 introduced a
regression whereby dlopen RTLD_GLOBAL of a library that was previously
loaded RTLD_LOCAL no longer promotes the library to the global
namespace as intended. This is easy to fix, but there are other
related bugs I've found in the process, and I want to document them
here. Some may be trickier to fix. They relate to the ->deps list for
a dso, which is supposed to contain a dependency-order list of dsos
that dlsym will search when called on the dso handle. These are also
connected to the stalled attempt to do dependency-order execution of
constructors.

1. Rather than building the deps list by recursive descent through
DT_NEEDED tables, it's built by iterating all libraries loaded after
the library whose deps list is needed (i.e. p->next to end). This is
correct only at the time of initial load of the library (when all new
additions to the list are its dependencies) and only if none of those
dependencies in turn have dependencies that happened to already have
been loaded earlier.

2. The deps pointer remains null if a library has no dependencies.
Since this pointer being null is also used to indicate that the deps
list was not yet built, if it's later dlopen'd again, a library that
had no dependencies will falsely get assigned the dependencies of any
libraries that were loaded after it but before the second call to
dlopen. In practice almost everything depends on libc.so, so this is
unlikely to show up in the wild. But:

3. Libraries that are loaded at startup do not have deps tables; they
only get them on the first dlopen. Like the above case, they will
falsely get assigned the dependencies of any libraries that happened
to be loaded after them, either at startup or by dlopen.

The issue of overloaded meanings for null deps pointer is easy to fix
on its own, so I'm going to try to go ahead and fix it along with
fixing the regression that started this investigation. But I think to
fix all these problems we really need to overhaul the way dependencies
are represented, and we may need to build the tables for all libraries
at the time they're loaded (especially if we want to do the ctor dep
order thing, which I still think makes sense) rather than deferring
until dlopen.

Rich

Re: Multiple bugs in dlopen & dependency tracking

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2017-07-04 10:53:28 -0400]:
> Commit 4ff234f6cba96403b5de6d29d48a59fd73252040 introduced a
> regression whereby dlopen RTLD_GLOBAL of a library that was previously
> loaded RTLD_LOCAL no longer promotes the library to the global
> namespace as intended. This is easy to fix, but there are other
> related bugs I've found in the process, and I want to document them
> here. Some may be trickier to fix. They relate to the ->deps list for
> a dso, which is supposed to contain a dependency-order list of dsos
> that dlsym will search when called on the dso handle. These are also
> connected to the stalled attempt to do dependency-order execution of
> constructors.

maybe adding debugging to the dynamic linker would help
finding these issues earlier (e.g. if LD_DEBUG is set
then print some trace to stderr in whatever format about
what the dynamic linker is doing) since using a debugger
on the dynamic linker is often non-trivial.