From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6C5E8385B528; Tue, 7 Mar 2023 16:50:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6C5E8385B528 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1678207820; bh=ezvd4PMsjm3HwgLI3nQs8GYX6cZoS/4FnB98iPA07m0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kWYPcnK3mfIkjQK+ajkDud+JWtXnFysdRLqV7wxq0zrQrnabI4i4cBVrH0+yG9Fal 8JAcnbTRrDwaMo0gBEQekKgJN5XpsfKvHrKUPiLhaI2RXKENbTvBP1UlloUukTfDEJ ICiMeCDbf++TUeW6PQM+d3/4GlNMa3a9zwYlJVtY= From: "stsp at users dot sourceforge.net" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/30127] [rfe]: enable ld audit at run-time Date: Tue, 07 Mar 2023 16:50:20 +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: stsp at users dot sourceforge.net 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 #40 from Stas Sergeev --- (In reply to Jonathon Anderson from comment #39)=20 > I think that should answer the later questions, but I'll try to be explic= it. 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? 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? 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? 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. Is that picture remotely correct? I guess no, as it is based on too many assumptions from me. :) > It's not. The la_objopen calls in dl_main() still happens before the init > constructors, so these calls are not late. ld.so currently contains no la= te > la_objopen calls. Yes, now I see what kind of "late" you mean: late for DT_NEEDED deps of the main executable. Is that correct? > The bigger issue is that the interface definition is very unclear on *whe= n* > 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 could > load and unload objects in parallel in different namespaces. If an auditor > receives an la_activity(ACT_ADD) callback, should it expect only la_objop= en > until the next la_activity? 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. :( 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? 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? > IMHO if you go that far, LD_AUDIT (the environment var) works just as wel= l. > And doesn't require recompiling the application with non-standard C. :D 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. > Anyway, my main concern is graceful handling for late notifications. Gett= ing > the auditor to load very early is a separate but less troublesome issue. If you can load it early enough then why would you care about telling it about "too late"? 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? --=20 You are receiving this mail because: You are on the CC list for the bug.=