From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 829193858D28; Sun, 26 Feb 2023 16:54:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 829193858D28 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1677430494; bh=y4apsbussWGyRC7ucxEkO181bcUsodqlyAlRztRyARg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Um8TNFKbX/vaSQ9CNItqcE9bu2w8MVgUei5WDHvd9soqFn4Eh8ttZxyl0dvW70kxb J+6glvlN0Lg6SEDGkqIn5CJVpwxfP6UQshVWH9LdJcduMI9cO2pO55hz71FrZl5Wdw gppjZ6fAFM0kxH3fSFNDxoBFQtzXr/cpPNZUrpeg= From: "janderson at rice dot edu" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/30127] [rfe]: enable ld audit at run-time Date: Sun, 26 Feb 2023 16:54:52 +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.38 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: janderson at rice dot edu X-Bugzilla-Status: UNCONFIRMED 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=3D30127 --- Comment #27 from Jonathon Anderson --- (In reply to Stas Sergeev from comment #22) > > This still doesn't solve the issue. Expanding a bit: say you load > > dlload_audit_module("my_auditor"), then dlopen("libmylib.so") and > > libmylib.so binds malloc from libc.so. my_auditor gets an la_objopen ca= ll > > for libmylib.so but not libc.so. What do you do about the la_symbind > > callback?: > > - If you send an la_symbind to my_auditor, the defcook will be an > > unrecognized cookie. > > - If you skip the call, my_auditor won't be able to intercept malloc = (and > > all other libc functions).=20 > > - If you NULL the defcook, my_auditor won't be able to wrap malloc et= c. > > since it can't (reliably) get the "original" function it would bind to.= And > > it's an API break, so you need to bump LAV_CURRENT. >=20 > In that case I think it would make > sense to disable symbind and plt call-backs > for such dynamic auditors? There *will* be auditors that will not function properly under these restrictions. At the very least there needs to be some kind of flag present= ed to the auditor at la_version-time to let it know that it has been loaded in this (very) degraded state, so the auditor has a chance to refuse to load. >=20 > > What is your proposed auditor supposed to do? >=20 > It supposed to use these audit extensions > https://sourceware.org/pipermail/libc-alpha/2023-February/145638.html > and apply other solib loading customizations. > But its not going to do anything after the > load process, i.e. I don't need symbind/pltenter. > I guess it would be fair to let the app-wide > auditors to work with all libs, and have the > dynamic auditors without any access to the > "outer" libs? So, IIUC you have an solib plugin (i.e. you don't control the application) where you want/need to customize (a) the location the solib is loaded (or w= here what the solib loads is loaded?) with la_premap and (b) the paths that your plugin loads with la_objsearch. Solibs are "position-independent" and should work no matter where they are loaded (unless you're doing *really* dangerous and non-portable tricks with function pointers). So (a) can only be a performance optimization, maybe improving I-cache locality? IMHO it makes more sense to apply such an optimization across the entire application. Or is there a reason why this should only apply to your plugin? (b) gives me bad vibes, it seems very easy to run into a situation where dlopen->dlclose->dlopen will unexpectedly give you different binaries betwe= en the two dlopen calls. la_objsearch also doesn't affect binaries that are already loaded, e.g. if an earlier plugin loads a library you wanted to rep= lace you will have lost the chance to do so (and you won't even get a callback warning that this is happening). IMHO it seems delicate unless applied consistently across the entire application. Is there a reason you can't manually adjust the paths your solib loads? Are the wanted paths dynamically generated (like e.g. Spindle[1])? [1]: https://computing.llnl.gov/projects/spindle --=20 You are receiving this mail because: You are on the CC list for the bug.=