[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 #36 from Jonathon Anderson <janderson at rice dot edu> ---
(In reply to Stas Sergeev from comment #34)
> (In reply to Jonathon Anderson from comment #33)
> > 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?
> 
> Sure!
> The sale point of that patch is to allow
> more convenient ways of communicating with
> an auditor. So of course there is such a way!
> In v9. :)

I must not be seeing this feature in the patch. Can you guide me a bit? I see
la_dynload which indicates when an auditor is dynamically loaded, but AFAICT
there isn't a way to tell which la_objopen callbacks are "real" (new objects)
or "fake" (objects already loaded).

I probably should have been clearer in my request, sorry.

(In reply to Stas Sergeev from comment #35)
> So while I added what you asked for,
> let me wonder why "missed the boat"?
> It seems gcc allows to specify the
> constructor priority. So why not to
> create the "first" constructor for
> loading audit modules,

How does that help? Constructor priority means nothing after the solib or
executable is linked. GCC/ld uses the priorities to sort the list of _init
functions within a single object. ld.so decides on the order objects run their
constructors based on dependencies between objects and nothing else.

(In reply to Stas Sergeev from comment #34)
> > Why would you have to lift the variables in the legacy code? Those are
> > already "inside" the VM, right?
> 
> No: VM is a part of compatibility layer.
> It allows those solibs built from ancient
> non-unix code, to work. And shim is gluing
> these 2 components together.
> So if solib calls something, shim forwards
> the call to VM,

So, let me just make sure I'm on the same page here: you have non-Unix (or even
pre-Unix?) code that's been compiled into 64-bit solibs. And you have
compatibility libraries to implement the non-Unix bits, but they're 32-bit only
and so need to run in a VM. So to get everything working, you need those two
kinds of libraries calling each other despite the complete ABI and ISA
difference, in a single process.

I assume there's a Very Good Reason (TM) the ancient code can't be compiled
32-bit (and run in the VM) nor the compatibility libraries compiled 64-bit (and
run without a VM). Otherwise you wouldn't need any of this.

I'm not confident this description is right based on your comments later... but
dang, this is quite a unique problem.

> but the call args must be
> all accessible to VM. So the libs are mapped
> to the 4Gb window where VM can see them, and
> that 4Gb window is not in the lower 4Gb, but
> rather somewhere in a 64bit space.

And the call args can contain pointers, thus the need to ensure the pointers
are in range. You can override malloc and new to (mostly) ensure heap
allocations are in the right region. The dlmem/la_premap patches(es) ensure
pointers to data segments will work.

What do you do about pointers to stack variables?

> > 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.
> 
> I still don't see how can this be done
> w/o rewriting the libs from scratches -
> the ones I do not control, I only have
> the control over the shim lib.

I'm beginning to understand this. If so, the question is indeed moot.

> 
> 
> > 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.
> 
> Its indeed the nice trick, but the problem
> is that I need a "disparity" between the
> relocated and mapped address.
> Relocated address is in MAP_32BIT, but mapped
> address = relocated_address+VM_window_start.
> Then VM sees the solib in its relocated address,
> which is the goal.

That... makes absolutely no sense. In that arrangement the loaded solib will be
useless outside the VM, the relocations are wrong for the 64-bit address space.
So why does the 64-bit ld.so need to load it? Can't you load it inside the VM
using the 32-bit ld.so, since that's the only place it could possibly work?

This seems to contradict your prior explanation too. Doing this will make a
64-bit solib useless, the relocations are wrong in 64-bit address space and the
32-bit VM can't run the code (wrong ISA). If you don't fully control the 64-bit
solib you're doing this torture to, there's no way you can expect this to work
at all.

> 
> 
> > 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.
> 
> I don't think the proposed scheme can be
> replicated by any tricks and hacks. And
> honestly I don't know why it should.
> There was that LD_PREFER_MAP_32BIT_EXE but
> it was dumb, so removed. Why not to replace
> it with something small and smart?

IMHO this is well outside the kinds of problems where a "small and smart"
solution is a tractable goal. After all, we're talking about multiple
architectures in a single process image. :P

> Esp given
> that there is a demand in a functionality of
> specifying the relocation address, it can be
> found on stackoverflow.
> There were multiple requests for dlmem(), too,
> both here and on steckoverflow. There are even
> some sketches on github from various people.

Mind providing a couple good sources for what you're referring to here?

I didn't get any relevant hits for "dlmem" on these sites or on Google.

> And finally you can also have that feature of
> "mmapped_addr!=relocated_addr" - all by the
> price of 1. :)

That's the part that makes no sense to me. Why would ld.so EVER load an solib
in an arrangement it won't be able to use? It can't even call the solib's init
constructors!

Which of course makes me question the intended stability of your "small and
smart" patches. There are plenty of ways to crash an application, let's not add
more, shall we? ;)

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