public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "stsp at users dot sourceforge.net" <sourceware-bugzilla@sourceware.org> 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 [thread overview] Message-ID: <bug-30127-131-dTgTRVC3DS@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-30127-131@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=30127 --- Comment #40 from Stas Sergeev <stsp at users dot sourceforge.net> --- (In reply to Jonathon Anderson from comment #39) > I think that should answer the later questions, but I'll try to be explicit. 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 late > 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 *when* > 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_objopen > 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 well. > 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. Getting > 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? -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2023-03-07 16:50 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-15 8:23 [Bug dynamic-link/30127] New: " stsp at users dot sourceforge.net 2023-02-16 18:42 ` [Bug dynamic-link/30127] " fweimer at redhat dot com 2023-02-17 2:54 ` stsp at users dot sourceforge.net 2023-02-17 7:17 ` stsp at users dot sourceforge.net 2023-02-17 8:08 ` fweimer at redhat dot com 2023-02-17 8:38 ` stsp at users dot sourceforge.net 2023-02-17 8:56 ` fweimer at redhat dot com 2023-02-17 9:32 ` stsp at users dot sourceforge.net 2023-02-17 9:38 ` stsp at users dot sourceforge.net 2023-02-17 9:44 ` stsp at users dot sourceforge.net 2023-02-17 10:23 ` fweimer at redhat dot com 2023-02-17 10:59 ` stsp at users dot sourceforge.net 2023-02-17 12:46 ` fweimer at redhat dot com 2023-02-17 13:43 ` schwab@linux-m68k.org 2023-02-17 13:55 ` stsp at users dot sourceforge.net 2023-02-17 13:57 ` stsp at users dot sourceforge.net 2023-02-20 8:33 ` fweimer at redhat dot com 2023-02-21 15:39 ` stsp at users dot sourceforge.net 2023-02-21 19:43 ` janderson at rice dot edu 2023-02-21 20:09 ` stsp at users dot sourceforge.net 2023-02-22 16:46 ` stsp at users dot sourceforge.net 2023-02-23 16:02 ` janderson at rice dot edu 2023-02-23 16:35 ` stsp at users dot sourceforge.net 2023-02-24 18:02 ` stsp at users dot sourceforge.net 2023-02-25 16:57 ` stsp at users dot sourceforge.net 2023-02-25 18:49 ` carlos at redhat dot com 2023-02-25 19:00 ` stsp at users dot sourceforge.net 2023-02-26 16:54 ` janderson at rice dot edu 2023-02-26 17:22 ` stsp at users dot sourceforge.net 2023-02-26 19:22 ` stsp at users dot sourceforge.net 2023-03-02 14:39 ` stsp at users dot sourceforge.net 2023-03-02 16:13 ` janderson at rice dot edu 2023-03-02 19:56 ` stsp at users dot sourceforge.net 2023-03-03 6:20 ` janderson at rice dot edu 2023-03-03 12:36 ` stsp at users dot sourceforge.net 2023-03-04 11:33 ` stsp at users dot sourceforge.net 2023-03-06 9:12 ` janderson at rice dot edu 2023-03-06 10:09 ` stsp at users dot sourceforge.net 2023-03-06 10:56 ` stsp at users dot sourceforge.net 2023-03-07 8:54 ` janderson at rice dot edu 2023-03-07 16:50 ` stsp at users dot sourceforge.net [this message] 2023-03-12 8:42 ` stsp at users dot sourceforge.net 2023-03-13 9:22 ` janderson at rice dot edu 2023-03-13 9:41 ` janderson at rice dot edu 2023-03-13 10:01 ` stsp at users dot sourceforge.net 2023-03-13 10:46 ` stsp at users dot sourceforge.net 2023-03-13 11:17 ` stsp at users dot sourceforge.net 2023-03-13 20:26 ` stsp at users dot sourceforge.net 2023-03-14 15:11 ` stsp at users dot sourceforge.net 2023-03-15 5:34 ` janderson at rice dot edu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-30127-131-dTgTRVC3DS@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).