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

["stsp at users dot sourceforge.net" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #37 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Jonathon Anderson from comment #36)
> (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

Well, v9 only addresses this:
"Is there a way to indicate to the auditor that it's \"missed the boat\""
by allowing you to tell anything you want to
an auditor.

> AFAICT there isn't a way to tell which la_objopen callbacks are "real" (new
> objects) or "fake" (objects already loaded).

There is no such thing simply because the
"late" objopen call is already an established
practice in dl_main(). Which means its a bit
out of the scope of this patch, but it doesn't
mean I can't add such a thing. For example I
can add la_objopen_late(). But let's see if it
is actually needed. For example can't you use
the fact that la_objsearch() and/or
la_activity(LA_ACT_ADD) wasn't called before
la_objopen()?


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

Yes, so you need to add the "primary" ctor
to the main object (not to any solib of it)
and from that load the audit module, no?


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

Exactly.


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

No, this is not the case. :)
I mean, the reason may be not Very Good (TM)
for your ears, but its just that it would need
the pretty much outdated tool-chains that no
one has these days. Also the ability to work
on host in 64bit mode provides performance and
other benefits. VM is much, much less involved
in that scenario, than when you run everything
inside VM. In theory, this will also allow to
extend the old code with some functionality
available on host, but that's not something to
anticipate at that early stage of a development.


> I'm not confident this description is right based on your comments later...

But actually your description is very relevant!


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

Indeed!


> What do you do about pointers to stack variables?

I can set up the initial stack from my
shim lib, and if an app wants to switch
stacks (which is very unlikely), it will
have to use the heap space, which is under
my control.


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

la_premap_dlmem() is a very powerful extension. :)
It allows you to map the lib anywhere you
want, any amount of times in a row. You can
map it to VM window _in addition_ to also
mapping it to its relocation point. That's
what even the test-case of mine demonstrates
by doing 2 mappings of the same lib. And let
me assert its very small for such a powerful
functionality, because all it does is to pass
the backing-store fd to dlmem. With that fd
you can do whatever you want. So no lots of
new and convoluted APIs, whereas the solved
task is quite big. For the price of just 1
small dlmem() call!


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

It should work in both "worlds" because it has
the regular DT_NEEDED deps linked with its
own custom libc. So the host relocations should
work properly, and only the shim lib translates
the calls into VM.


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

I think LD_PREFER_MAP_32BIT_EXE was also
about something like this. So my demand is
definitely not the first one.
But let's look at it from another side:
all I do is specify the reloc address and
pass a backing-store fd. No matter what
arch problems does this solve, its simple
by itself and only adds 1 API func that people
requested many times. I am sure next time
you'll deal with dozens of APIs to solve only
some small part of the same problem. :) My
impl is exceptionally minimalistic, I am quite
confident in that.


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

Will do in an hour or so.
Give me some time to collect the links for you.

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