[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 #33 from Jonathon Anderson <janderson at rice dot edu> ---
(In reply to Stas Sergeev from comment #32)
> (In reply to Jonathon Anderson from comment #31)
> > I can't say the current solutions are appealing. You've made it very
> > difficult for a dynamically-loaded auditor to accomplish any auditor-like
> 
> Posted v7 which just calls la_objopen()
> for pre-existing libs, similar to dl_main().

So, my group currently assumes la_objopen() happens before the init
constructors of the referenced objects. It turns out to be an important
callback for registering callbacks in runtime libraries before transferring
control back to the application. Is there a way to indicate to the auditor that
it's "missed the boat" so auditors that need this timing can recover
gracefully?

> 
> > You mentioned in another ticket
> > (https://sourceware.org/bugzilla/show_bug.cgi?id=30007#c2) that the whole
> > point of this is to access data objects in the solib. Do you write this
> > solib?
> 
> I write a shim that should load (via dlmem()) other
> libs, built from some 30 years old sources (that neither
> me nor anyone else writes today), and allows them to work
> on a current system. I.e. this is a compatibility layer.
> Compatibility layer, unfortunately, can't require changing
> the legacy code. What you propose, will require mostly a
> full rewrites, eg I have no idea how would the one identify
> all pointers to all vars and change all such vars to a heap
> objects...

Why would you have to lift the variables in the legacy code? Those are already
"inside" the VM, right?

What it sounds like you're trying to do is pass a pointer to the data segment
of a 64-bit library "outside" the VM to the 32-bit legacy code running "inside"
the VM. Which it will then dereference to access or alter some variable shared
"across the VM gap." Does this match your use case?

If you control this 64-bit library, you should be able to lift the shared
variables to pointers. Just allocate them "inside" the VM's more restrictive
address space and reference from "outside." In this case Glibc doesn't even get
involved.

The only reason you would require dlmem() or la_premap is if you didn't control
the 64-bit library who's data segment needs to be shared "across the gap." Is
this the case?

> 
> > Could you override mmap itself for the files you want mapped in the right
> > locations?
> 
> But it won't be relocated to that address.

The result of the first call to mmap() for an solib decides the base address
for the solib, which is the address all relocations are relative to. So it
should relocate to the right address if your mmap wrapper is sane. See
_dl_map_segments (esp. lines 85-95 and 106) and _dl_map_segment.

There's a performance penalty to syscall wrapping (and it's arch-specific and
ugly), but AFAICT it should work just fine for this case.

> 
> > You mentioned DT_AUDIT wouldn't work, so I presume the executable is out of
> > your control, e.g. you're extending a VM with an solib plugin? If so, do you
> > not have the access to set LD_AUDIT in the environment before launching the
> > executable? You can always make your auditor "no-op" except when needed.
> 
> This is possible but a quite clumsy solution IMO.
> And of course it would still need all other patches
> (dlmem etc) except this one. So I'd rather concentrate
> on making dlload_audit_module() suitable for your needs.

This solution matches well with the (few) use cases auditors have been tested
in so far. If you want something that *works* (reliably) for this rather
specific use case, a little clumsiness is the least of your worries IMHO.

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