From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AAB2B3858D34; Thu, 8 Aug 2024 22:11:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AAB2B3858D34 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1723155119; bh=4ZIvnPSP+pNvG4d/XQEfkFxsOx1kYiCwEEXNVzd8fWM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TN/X5qxXUDp2Nw5LT35cVPydoJKHijqM7KVGdoMDpkLMS9qtuHGpYqsjFKRTCW4Db l5etDUPUUsqG8qfVbyp3a4amWMWpJu3zCihsUE7KASC8KA2l7Z/AOOntC2AlZ6BMtm t49AOLokYcxC76WI7RWIlq5qOkbdwKHCg7YWB1EQ= From: "woodard at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/31992] Dynamic loading from within 2nd auditor is not reported to the 1st auditor properly Date: Thu, 08 Aug 2024 22:11:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.39 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: woodard at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31992 --- Comment #2 from Ben Woodard --- (In reply to Florian Weimer from comment #1) > Regarding (1), (3), (4), (5), this is expected behavior. Auditors are not > themselves subject to auditing within their own namespaces.=20 In case [1] (and also in [3] [4] [5]), the first auditor is not expecting to audit its own namespace. It is expecting to be able to audit the second auditor's namespace. The classic example where this comes up is when the us= er trys to use two incompatible tools. For example say there is an MPI traffic analysis tool that must be compiled against the system's MPI version. The f= irst tool is reflectively aware that it has been compiled against one flavor of = MPI but then notices that as the second auditor the user has specified an audit= ing tool for a different flavor of MPI. Since this happens quite a lot as user = cut and paste things around, the first auditor knows the location of the second tool but compiled with the correct flavor of MPI.=20 You can see that the first auditor is not trying to audit its own namespace= .The command line is: LD_AUDIT=3D./auditor.so:./victim.so ./main The first error is: [audit] Expected la_objsearch for victim.so, FAIL. ./victim.so is the second auditor and it is in its own namespace. If the first auditor saw an la_objopen() for ./victim.so when the second au= dit library was being loaded it would have recorded that fact when it hit line = 11 in auditor.c: 10 char* la_objsearch(const char* name, uintptr_t* cookie, unsigned int flag) { 11 if(strcmp(name, "./victim.so") =3D=3D 0) victim |=3D bit_search; Each individual auditor is in its own private namespace. All auditors are n= ot in one single namespace. There is a specified ordering to auditors: LD_AUDIT=3D::... application where the application subsequently can have DT_AUDIT libraires that are loa= ded after the auditors specified in the environment variable but before the application.=20 So the ultimate order would be: ... ... application The expectation is that auditors which are further away from the applicatio= n in this ordering should see events by auditors closer to the application. The final auditor would only see events from the applictation itself. It seems that the __RTLD_AUDIT flag is being applied over broadly preventing auditors from overseeing other auditors closer to the application. The general direction that the tools community is going is to abandon old tooling interfaces such as LD_PRELOAD which are almost impossible to stack = and replace them with stacks of audit libraries. Some of these are going to be linked with DT_AUDIT for always on functionality and others are going to be specified through the LD_AUDIT environment variable. Some examples are: hpctoolkit (a performance tool) combined with spindle (an audit library that makes use of multicast like capabilities of the backend network fabric to m= ore quickly load MPI applications and all their libraires on the hundreds of compute nodes participating in a job) combined with a next generation malloc replacement which is is written as an audit library. Other ideas include having an ABI checking library to verify that all the versions of the libs found when traversing the user's LD_LIBRARY_PATH are in fact ABI compatible and that the ABI of some seldom used call in some GPU library didn't change ABI between version 6.1.1 and 6.1.2 only to be discov= ered with a crash after several hours compute time across hundreds of compute no= des. This ABI checking audit library would copuld be combined with any of the aforementioned audit libraries like hpctoolkit or spindle. A MPI replacement/thunking layer audit library which substitutes a generic = MPI that any application can be compiled against with one that is specific to t= he supercomputer. A MPI communication monitoring tool which helps identify communication bottlenecks in an application. Similarly an audit library that substitutes a fixed or locally optimized version of a library for one that is known buggy or hasn't been optimized without requiring the user to relink thier application. All of these things may be used individually or combined. One of the deficiencies of older tooling interfaces like LD_PRELOAD was the function wrapping and isolation of symbols was not sufficient to allow multiple different tools to be combined. That is one of the features driving us towa= rd increasing use of LD_AUDIT. The other feature is that our developer tools group can easily provide reci= pes to our developers allowing them to link in tools using DT_AUDIT so that the= se tools can be "always on". This appears to be less error prone than giving developers long LD_AUDIT and LD_LIBRARY_PATH environment variables when ask= ing them to always use a particular tool. --=20 You are receiving this mail because: You are on the CC list for the bug.=