RFC: Auditor access to program headers

[Jonathon Anderson <janderson@rice.edu>]

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