RFC: Auditor access to program headers
Jonathon Anderson
janderson@rice.edu
Wed Mar 16 18:25:53 GMT 2022
Hello all,
We (the HPCToolkit team) recently encountered a new complication using
LD_AUDIT as part of the HPCToolkit performance tools. In one shared
library we encountered, the program headers are mapped in a PT_LOAD
segment to a different virtual offset than their file offset. This
caused our auditor to crash since we had previously assumed these
offsets would be identical. Without this assumption, we cannot access
the mapped program headers for a binary. While we can work around the
issue (with a serious performance hit) by opening the file to read the
headers ourselves, it does concern us that there is no secure (or fast)
way for an auditor to access the program headers for a loaded binary
without horrific dl_iterate_phdr shims.
We propose two changes to support this use case:
- Addition of a new dlinfo request that fills a dl_phdr_info (or
similar) structure identically to how dl_iterate_phdr would. This would
enable access to a load module's program headers without use of
dl_iterate_phdr.
- A fix for the bug that causes dl* functions to crash in early
auditor notifications (one of our Tier 2 issues). This is required to
allow use of dlinfo within an auditor. Fixing this involves adjusting
rtld_active to return true during auditor notifications in dl_main.
These two changes should have no ABI impact. It would help us greatly if
these changes were made and backported to supported Red Hat versions,
including the upcoming Fedora 36 release.
For additional clarity, it would also be helpful to have either:
- documentation that a link_map* is in fact a dlopen handle and thus
can be passed to any dl* function in current and future versions of
Glibc, or
- the prototype of la_objopen altered to take a void* dlopen handle
instead of a link_map* (which AFAIK currently has no or minimal ABI impact).
-Jonathon
More information about the Libc-alpha
mailing list