[Bug dynamic-link/30127] [rfe]: enable ld audit at run-time

[stsp at users dot sourceforge.net]

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.