Add support for the GLOBALAUDIT tag in the dynamic
section created by the linker.
This tag will allow the loader to be informed of dynamic
objects that should be loaded and run before the
executable itself is loaded.
Support for the GLOBALAUDIT feature is now implemented
in the linker. A change to the loader is still needed.
+++ This bug was initially created as a clone of Bug #1439350 +++
Description of problem:
At LLNL there are computational physicists who design interesting data sets that explore interest physics but who are not computer scientists. They run applications provided to them by computer scientists whose job is to implement the physics and make the binaries. The people who write and compile the programs are different than the people who generally run them.
The tools team at the lab generally would like to work the the computer scientists to provide tools that do various things. Several of their tools end up being implementable as audit libraries. One example is spindle http://computation.llnl.gov/projects/spindle another example is the common practice of wrapping library functions. In static cases wrapping can be done with LD_PRELOAD but to generalize the capability making it into an audit library that replaces the symbol and then calls the original is more effective.
In these cases the tools people want to work with the computer scientists and have them simply link in a tool library which is an audit library. An interface something like:
ld -faudit audit_lib.so foo.o bar.o -l libfoo.so ... -o exe
So that an original computer scientist can permanently have an audit lib loaded when the executable is run as if it were run like:
LD_AUDIT=audit_lib.so exe args...
ld.so would see the DT_NEEDED with some magic flag somewhere which says that this should be loaded as an audit library and dlmopened first and called the same way and the same times as if it were specified in the LD_AUDIT environment variable. This way it can replace the functions the way that spindle does or wrap the functions as needed.
This would require a new option to ld to specify the audit libraries to be linked in. That is more of a binutils feature. However, it would also require a change to ld.so which is part of glibc.
1) multiple audit libraries may be specified.
2) it is important that debuggers are able to debug code that is brought in through these audit libraries. Thus tools like GDB need to be able to find the link maps and enumerate the symbols in libraries which are brought in this way.
--- Additional comment from Red Hat Bugzilla Rules Engine on 2017-04-05 14:57:48 EDT ---
Since this bug report was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
My first thought is - is this really necessary ? Given that the desired effect can be achieved by using LD_AUDIT on the command line, why not just bundle that up into a small script and have the computer scientists run that ?
My second thought is that the "common practice of wrapping library functions" can be achieved with the already existing --wrap static linker command line option, so maybe that could be used instead ? (I appreciate that this would not work for spindle though).
My third thought is that if we are going to add this functionality to the static and dynamic linkers then we are going to need to come up with a proper specification for it, get people like Intel and IBM on board, and then add it to the gABI. This can be done, but it probably won't be quick.
My last thought is - could this feature be used maliciously ? For example could an attacker use it replace existing, thought-to-be-safe binaries with their own "enhanced" versions which do something on the side ? If so, then do we need to involve the security team as well ?
After long experience with the current capabilities of LD_AUDIT, the customer does believe that this is a necessary feature. While conceivably UNIX and Linux could function with only a simple read(2) syscall, experience has show that while parsimony is a virtue, the diversity of use cases has led to readv, pread, mmap'd IO with blocking, non-blocking, signal driven IO... The point is minimalism is doesn't always allow needed expressivity to achieve optimal performance and therefore productively.
I'm going to make the assertion that this is a well considered request made by well seasoned professionals with combined decades of experience who are familiar with the alternatives made an explicit request.
I didn't see this coming and my first thought was to suggesting wrapping things in scripts like you suggested. However with parallel job launchers setting up the MPI fabric and starting up the applications on the compute nodes and giving them ranks, it isn't quite as simple just wrapping everything in a script. When you combine that with the organizational and the various capabilities of people providing different skills to the overall endeavor, the need for this becomes more obviously necessary.
This is needed. There are many cases where environment variables cannot be passed down for design reasons.
As noted here: https://bugzilla.redhat.com/show_bug.cgi?id=1439350#c2
A Solaris design already exists for this.
e.g. -Wl,-Paudit.so.1 -z globalaudit
And we have ELF DT_* entries for this already in binutils. We'd just have to wire up that support in Linux so the dynamic loader can use it.
Created attachment 1313181 [details]
This is the patch that will implement the required functionality in the binutils.
When this BZ gets its three ACKs I will add it to the rpm.
Right - the binutils part of the patch is now in: binutils-2.27-29.base.el7
Verified with build binutils-2.27-34.base.el7.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.