The ABI status of ELF hash tables

Posted Aug 19, 2022 18:32 UTC (Fri) by ndesaulniers (subscriber, #110768)
Parent article: The ABI status of ELF hash tables

> When the dynamic linker starts a program, it must resolve all of the symbol references into shared libraries (including glibc).

> Since this process must complete before an application can actually start running, it needs to happen quickly.

I don't think that's generally true; it relies on the executable being linked with `-z now`, otherwise the symbols are resolved lazily (ie. the whole dance with the GOT and PLT). I suspect the implicit default for this flag is configure-able in GNU BFD though, and at this point I suspect most distros would set that as the default. This adds a layer of protection to prevent tampering with the GOT and PLT at runtime.

When symbols are resolved lazily, not "all" symbols references need to be resolved, and the process doesn't need to "complete" before the process starts running.

The ABI status of ELF hash tables

Posted Aug 19, 2022 19:31 UTC (Fri) by ndesaulniers (subscriber, #110768) [Link]

I suspect the EAC developers just implemented scanning the simpler and documented symbol table section.

That said, if glibc can break abi like this, I wonder if we can drop --hash-style=both from VDSO's in the kernel and just support DT_GNU_HASH?

(Fun fact: I once had a bug where one of these sections (DT_GNU_HASH) wasn't being produced; I could only repro on builds from the server and not locally. I had to use `dd` to slice the vdso out of a running process on device using a build from the server. Ultimately, kbuild wasn't hermetic, and the server's linker was missing support for --hash-style=both. https://stackoverflow.com/a/54797221).

The ABI status of ELF hash tables

Posted Aug 19, 2022 22:56 UTC (Fri) by jreiser (subscriber, #11027) [Link] (1 responses)

> -z now ... adds a layer of protection to prevent tampering with the GOT and PLT at runtime.

There is no protection against tampering unless (in addition) various parts of the PLT (ProgramLinkageTable) are put into a .relro section and then into a PT_LOAD segment that lacks PROT_WRITE.

Part of the original impetus for -z now was to prevent spending hours and hours during the first phase of a computation, only to have the process abort because some symbol relating only to the second phase could not be resolved due to mismatch of shared libraries or other configuration problems.

-z now can interfere with explicit dlclose(); ...; dlopen() for managing a multi-phase program in a constrained address space, or user interaction that explores optional (but known-in-advance) "heavy weight" subsystems.

The ABI status of ELF hash tables

Posted Aug 23, 2022 1:49 UTC (Tue) by bartoc (guest, #124262) [Link]

The "norm" should probably be to use -z defs -z lazy --no-allow-shlib-undefined. That is "report a link-time error if any symbols are undefined, but don't tell the loader to resolve all symbols at startup, and also report undefined symbols that are in shared libraries I linked to". For a lot of applications using "-z now" is allright, but for a lot of libraries (and some apps) -z lazy is better because the set of used symbols depends highly on the path execution takes. Think of a library like OpenImageIO or VTK that has a ton of format parsing libraries linked to it, most of which won't be used by a given application.