[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 #34 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(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. :)


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


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

Indeed.


> 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.
Now suppose I do have a control over the
actual solib (actually not, but if), and
then what? It can do thousands of calls,
any of them can have pointers to its own
local or global data, variables, whatever.
I do not control these libs (the compatibility
layer is the final product, libs are on
user's side), but even if I do, I would
have to walk through all its intercepted
calls and convert all referenced objects
to a heap objects - heap objects can indeed
be allocated on the VMs side, and in fact,
the heap objects _will_ be allocated on a
VMs side. But I can't estimate the work of
converting all addressable objects to heap
objects, even if I could control all those
solibs.


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

Yes, it is the case.
I only control shim lib.
But I don't believe even the "otherwise" would
help much. Compatibility layer that requires
you to rewrite everything, is not of a big use.


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


> 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? 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.
And finally you can also have that feature of
"mmapped_addr!=relocated_addr" - all by the
price of 1. :)
Why even try to replicate that with tricks
and hacks?
But I think its impossible w/o my patches,
anyway.

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