[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 #43 from Jonathon Anderson <janderson at rice dot edu> ---
Going back to your use case:

(In reply to Stas Sergeev from comment #37)
> > 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. 
I can consider that a good enough reason not to compile the ancient code as
32-bit. But the compatibility libraries are surely much newer, can't they be
compiled 64-bit?

> Also the ability to work
> on host in 64bit mode provides performance and
> other benefits. 
It does. Can you compile the compatibility libraries as 64-bit instead? :D

> 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.
> 
> 
> > 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.
How? The initial stack is set up by the kernel before the executable is even
mapped. Do you switch stacks in your shim library, after the VM memory region
is decided upon?

While on the topic (and mostly out of curiosity), what do you do when the
64-bit code allocates more than 4GB of memory? It obviously won't all fit in
the VM's address space, so a pointer could be passed through the shim lib that
would end up out of bounds.

> 
> 
> > 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. 
...If all you wanted was to mmap the solib to another address, you can already
do that using mmap and /proc/self/map_files/. Maybe dl_iterate_phdr. No
la_premap or dlmem() needed.

The only reason any extension to Glibc is needed is if you wanted
(reloc_base_address != mmap_address). Which, to reiterate, is completely
nonsensical.

> 
> 
> > 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 really don't understand. The ISA is different between the "worlds," the
relocation base address will always be wrong in one "world" and make the solib
useless there. Heck, even the ELFCLASS is different.

I see no way for an solib to function in both "worlds." AFAICT the best you can
do is "manually" (i.e. not via data symbols) access the data segment from the
"other world," functions simply won't work.

> 
> 
> > > 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. 
You can specify the backing-store fd with classic dlopen and /proc/self/fd/.
That's a very simple solution, and requires no changes to Glibc.

You can choose the reloc base address (== mmap address) by overriding mmap.
That's not a simple solution, but it doesn't require a new interface or Glibc
patches. As noted above, I'm not yet confident your use case would work even if
you could specify the reloc base address.

I don't see any reason to support the (reloc base address != mmap address)
case. It's utter nonsense.

(In reply to Stas Sergeev from comment #38)
> So dlmem was requested:
> https://sourceware.org/bugzilla/show_bug.cgi?id=11767
> https://stackoverflow.com/questions/5053664/dlopen-from-memory
> https://stackoverflow.com/questions/29637464/need-an-api-that-allows-me-to-
> load-a-shared-object-from-a-memory-address
> 
> And even implemented:
> https://github.com/m1m1x/memdlopen
AFAICT these discussions are all solved by memfd_create. Almost all of the
complaints revolve around the memory vs. disk performance difference,
memfd_create is a very easy way to get a memory-backed file on modern Linux
boxes.

> 
> Mapping to specific address was requested:
> https://stackoverflow.com/questions/62064806/is-there-a-way-to-specify-the-
> base-address-of-a-shared-library-using-dlopen
I'm as confused as the answer's author on what the OP's actual use case is
here. Given the OP's lack of response to the request for context, I wouldn't
consider this worth much attention.

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