Hi Ben,

  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 ?

Cheers
  Nick

Nick,
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.

https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/gfido/index.html

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]
Proposed patch

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.

https://access.redhat.com/errata/RHSA-2018:3032