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

["janderson at rice dot edu" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=30127

--- Comment #42 from Jonathon Anderson <janderson at rice dot edu> ---
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) 
> > 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?
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 convenient
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 because
I would think that a feature that allows for dynamic loading of auditors should
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 load
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 think
that logic would apply just as well to the vast majority of other auditor use
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.

> 
> 
> > 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?
And any other solibs loaded before the dlload_audit_module call, but yeah.

> 
> 
> > 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?
Not really, we support too many different versions of Glibc to make that
viable. :P

> 
> 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 executable,
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], should
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.)

> 
> 
> > 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.
Indeed. My primary goal is to ensure the proposed "tools" for your use case
don't unwittingly destroy my use case in the process. :)

> 
> 
> > 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?
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.