Bug 1439351 - [LLNL 7.5 FEAT] RFE create an option to permanently link in audit library into an executable (binutils)
Summary: [LLNL 7.5 FEAT] RFE create an option to permanently link in audit library int...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: binutils
Version: 7.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 7.6
Assignee: Nick Clifton
QA Contact: Miloš Prchlík
Keywords: FutureFeature
Depends On: 1265827
Blocks: 1565233 1566146 1562804
TreeView+ depends on / blocked
Reported: 2017-04-05 18:59 UTC by Ben Woodard
Modified: 2018-10-30 07:51 UTC (History)
14 users (show)

  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.
Clone Of: 1439350
: 1566146 (view as bug list)
Last Closed: 2018-10-30 07:50:06 UTC

Attachments (Terms of Use)
Proposed patch (2.48 KB, patch)
2017-08-14 13:55 UTC, Nick Clifton
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:3032 None None None 2018-10-30 07:51 UTC
Red Hat Bugzilla 1439350 None NEW glibc: [RFE][LLNL 7.5 FEAT] Create an option to permanently link in audit library into an executable (glibc) 2019-05-23 15:22 UTC

Internal Trackers: 1439350

Description Ben Woodard 2017-04-05 18:59:45 UTC
+++ 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.

Additional info:

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.

Comment 2 Nick Clifton 2017-04-07 08:01:48 UTC
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 ?


Comment 3 Ben Woodard 2017-05-02 01:22:37 UTC
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.

Comment 4 Carlos O'Donell 2017-05-02 10:35:59 UTC
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.

Comment 9 Nick Clifton 2017-08-14 13:55 UTC
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.

Comment 12 Nick Clifton 2018-04-11 16:15:59 UTC
Right - the binutils part of the patch is now in: binutils-2.27-29.base.el7

Comment 14 Miloš Prchlík 2018-08-14 15:19:23 UTC
Verified with build binutils-2.27-34.base.el7.

Comment 16 errata-xmlrpc 2018-10-30 07:50:06 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.