[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 #27 from Jonathon Anderson <janderson at rice dot edu> ---
(In reply to Stas Sergeev from comment #22)
> > This still doesn't solve the issue. Expanding a bit: say you load
> > dlload_audit_module("my_auditor"), then dlopen("libmylib.so") and
> > libmylib.so binds malloc from libc.so. my_auditor gets an la_objopen call
> > for libmylib.so but not libc.so. What do you do about the la_symbind
> > callback?:
> >   - If you send an la_symbind to my_auditor, the defcook will be an
> > unrecognized cookie.
> >   - If you skip the call, my_auditor won't be able to intercept malloc (and
> > all other libc functions). 
> >   - If you NULL the defcook, my_auditor won't be able to wrap malloc etc.
> > since it can't (reliably) get the "original" function it would bind to. And
> > it's an API break, so you need to bump LAV_CURRENT.
> 
> In that case I think it would make
> sense to disable symbind and plt call-backs
> for such dynamic auditors?

There *will* be auditors that will not function properly under these
restrictions. At the very least there needs to be some kind of flag presented
to the auditor at la_version-time to let it know that it has been loaded in
this (very) degraded state, so the auditor has a chance to refuse to load.

> 
> > What is your proposed auditor supposed to do?
> 
> It supposed to use these audit extensions
> https://sourceware.org/pipermail/libc-alpha/2023-February/145638.html
> and apply other solib loading customizations.
> But its not going to do anything after the
> load process, i.e. I don't need symbind/pltenter.
> I guess it would be fair to let the app-wide
> auditors to work with all libs, and have the
> dynamic auditors without any access to the
> "outer" libs?

So, IIUC you have an solib plugin (i.e. you don't control the application)
where you want/need to customize (a) the location the solib is loaded (or where
what the solib loads is loaded?) with la_premap and (b) the paths that your
plugin loads with la_objsearch.

Solibs are "position-independent" and should work no matter where they are
loaded (unless you're doing *really* dangerous and non-portable tricks with
function pointers). So (a) can only be a performance optimization, maybe
improving I-cache locality? IMHO it makes more sense to apply such an
optimization across the entire application. Or is there a reason why this
should only apply to your plugin?

(b) gives me bad vibes, it seems very easy to run into a situation where
dlopen->dlclose->dlopen will unexpectedly give you different binaries between
the two dlopen calls. la_objsearch also doesn't affect binaries that are
already loaded, e.g. if an earlier plugin loads a library you wanted to replace
you will have lost the chance to do so (and you won't even get a callback
warning that this is happening). IMHO it seems delicate unless applied
consistently across the entire application. Is there a reason you can't
manually adjust the paths your solib loads? Are the wanted paths dynamically
generated (like e.g. Spindle[1])?

[1]: https://computing.llnl.gov/projects/spindle

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