From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id ACC673858C52; Mon, 13 Mar 2023 09:22:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ACC673858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1678699365; bh=M8QneniMatp1Om05UKG6YLx+92rw3lkerMtvwWmMgTw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=j9U3IduaXQvCoyrokbDfh+lEj5wdspidO4e+CnCLZjvfG/LK74spwAMSJT0vToGLw L7mFiseTZpDymyqvIBq3b42qzJ3THEYBre0jEwe4Mi98DvPzNjr1KX+A9ufP7IH11D 1SWoQBpM43BFKUl+4LofvtVeh7UM4VrmjNk7mffA= From: "janderson at rice dot edu" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/30127] [rfe]: enable ld audit at run-time Date: Mon, 13 Mar 2023 09:22:43 +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 #42 from Jonathon Anderson --- Sorry for the delay, this fell lower on my list than intended. (In reply to Stas Sergeev from comment #40) > (In reply to Jonathon Anderson from comment #39)=20 > > I think that should answer the later questions, but I'll try to be expl= icit. >=20 > So it seems you are saying that even the very > first ctor is too late because you want to audit > the loading of DT_NEEDED deps of the main executable > itself? Or have I missed your point? More or less right, IF libcuda.so is one of those deps. If libcuda.so isn't involved or is loaded after the auditor is, I can recover and still operate= as intended. > If that's the case then am I right that you can't > even change the app you audit, so dynamic loading > of an audit modules is completely out of the scope > for you? My team has managed to avoid changing the app so far, it's much more conven= ient for us to keep it that way. We have no reason to dynamically load our auditor. However, my team does implement a real, live auditor that is used in the wild. I bring it up beca= use I would think that a feature that allows for dynamic loading of auditors sh= ould support all auditors, as much as physically possible. That includes my team= 's auditor. After all, all solibs are perfectly functional regardless of whether you lo= ad it via LD_PRELOAD or dlopen or DT_NEEDED. Shouldn't auditors follow the same principle? > And do you mean that you need that only for libcuda, > while for other libs you can use dynamic loading, > which, presumably, means calling dlload_audit_module() > from some call-back of a libcuda auditor? No. What I mean is that libcuda.so is one of the only libraries I need to register callbacks for. For the vast majority of libraries I don't need to = hit the narrow timing window and can work fine with "late" la_objopen calls. It= 's the la_objopen for libcuda.so that I cannot handle being "late," if that happens I would need to error out to prevent crashes later down the line. > Because > I think you aren't changing the app you audit. > From that picture I think you have 2 audit modules, > one should be loaded with LD_AUDIT no matter what, > and another one can be loaded late but it needs to > know which lib was "already there" and which not. A second auditor would be overkill, once you have one loaded with LD_AUDIT = you can "see" everything going on already and don't need a second auditor. I th= ink that logic would apply just as well to the vast majority of other auditor u= se cases. > Is that picture remotely correct? I guess no, as > it is based on too many assumptions from me. :) It's in the right direction. The only reason I bring up my use case is as an example auditor that would be broken by this dynamic loading feature in its current state. >=20 >=20 > > It's not. The la_objopen calls in dl_main() still happens before the in= it > > constructors, so these calls are not late. ld.so currently contains no = late > > la_objopen calls. >=20 > Yes, now I see what kind of "late" you mean: > late for DT_NEEDED deps of the main executable. > Is that correct? And any other solibs loaded before the dlload_audit_module call, but yeah. >=20 >=20 > > The bigger issue is that the interface definition is very unclear on *w= hen* > > la_activity is called around la_obj* and the scope in which it applies. > > Glibc maintains the internal link_map state under a single lock, but one > > could imagine a more flexible implementation where multiple threads cou= ld > > load and unload objects in parallel in different namespaces. If an audi= tor > > receives an la_activity(ACT_ADD) callback, should it expect only la_obj= open > > until the next la_activity? >=20 > Ah, that's right... I thought la_activity() > is called with all link-maps, but now I see > it is only called for NS head, so you can't > rely on such an ordering by using cookies. :( >=20 > Note however that struct link_map has > "l_init_called". Unfortunately there are 2 > struct link_map's, one of which doesn't have > it. Is it a viable solution for you to peek > into an "extended" link_map structure? Not really, we support too many different versions of Glibc to make that viable. :P >=20 > Also I still can't discount la_objsearch(). > Even if it isn't called for vdso, is it a big > problem for you to assume that "vdso ctors > already executed"? Does vdso have any ctors > at all? The finite set of "expected" non-la_objsearch objects (vDSO, main executabl= e, ld.so) are easy enough to deal with. The bigger problem is the much larger = set of unexpected non-la_objsearch objects, such as the old (DNS? libresolv?) library or the objects loaded by the proposed dlmem(). The parallelism issue is present here too. There's no association between an la_objsearch and the resulting la_objopen, so if the auditor receives the callback sequence [la_objsearch, la_objsearch, la_objopen, la_objopen], sho= uld it expect the second la_objopen to be "late" or not? (la_objsearch can also= be called multiple times for the same path as it gets transformed, so counting isn't a solution.) >=20 >=20 > > IMHO if you go that far, LD_AUDIT (the environment var) works just as w= ell. > > And doesn't require recompiling the application with non-standard C. :D >=20 > You forgot that the requirement of calling > an auditor before any ctors, is not a global > one. :) Its your use-case, mine doesn't have > such a requirement. Which is why I think my > use-case deserves proper "tools", whereas for > your use-case LD_AUDIT is the proper tool. Indeed. My primary goal is to ensure the proposed "tools" for your use case don't unwittingly destroy my use case in the process. :) >=20 >=20 > > Anyway, my main concern is graceful handling for late notifications. Ge= tting > > the auditor to load very early is a separate but less troublesome issue. >=20 > If you can load it early enough then why would > you care about telling it about "too late"? >=20 > And also I probably haven't yet spelled out > the v9 change. Since you now can have la_dynload(), > can you assume that after la_dynload() any objopen > is "late" until LA_ACT_CONSISTENT is called? > I think LA_ACT_CONSISTENT will be called even > at the end of dlload_audit_module() itself. > So la_dynload() and LA_ACT_CONSISTENT do look > like a good markers? If the interface is defined such that no other la_objopen calls from threads running in parallel can trigger before that first la_activity(CONSISTENT), = then I could consider that a reasonable enough solution. --=20 You are receiving this mail because: You are on the CC list for the bug.=