[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 #45 from Stas Sergeev <stsp at users dot sourceforge.net> ---
(In reply to Jonathon Anderson from comment #43)
> 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?

Indeed, that's the case.
I wouldn't go into such a long and deep
hoops (where glibc is by far not the only
obstacle) to just compile things for 32bits. :)


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

The initial stack of what?
Of an executable - indeed.
But not of the lib I run through dlmem().
I call its entry manually, after setting
up the things (including stack).


> Do you switch stacks in your shim library, after the VM memory
> region is decided upon?

Indeed. These things are done through
makecontext().


> While on the topic (and mostly out of curiosity), what do you do when the
> 64-bit code allocates more than 4GB of memory?

This 64bit code is compiled from ancient
sources, that shouldn't do that. So if it
does, it will just get the malloc() failure.
I run it with the custom libc - that allows
me to control everything. No direct host
calls are allowed. I am using RTLD_DEEPBIND
and a new NS. Well, "using" is a too loud
statement, as before things settled to glibc,
I have only a rough tests and prototypes.
But I tried similar concepts in the past,
so I am pretty sure the scheme is functional.


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

That can only work for loadable sections,
I believe. .bss cannot be shared that way,
and likely much more.


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

But as I already mentioned, I do 2 identical
mappings. One at reloc address, one at mmap
address. So even though reloc_address!=mmap_address,
things do work, because because the one at
mmap_address is only used for data accesses,
and the one at reloc_address is used for
everything (like code calls).


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

Not quite useless: data access by 32bit
code is done there. Everything else is done
at another address. So every mapping does
only what it can.


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

Indeed!
Functions will work when shim calls them
(via the right mapping).
"not via data symbols" is not a problem,
because when the call is in the VMs "world",
it has the ready to use pointers inside the
call arguments, and nothing else. Only these
pointers should work there. These pointers
lead to a reloc address, but because the VM
window is itself shifted, they need to go
through the alias at mmap_address to reach
their destination at reloc_address.
mmap_address=reloc_address+VM_window_start


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

Not sure I understand that part.
dlopen() uses source fd to map it to reloc_address,
but the data sections are just anonymously
mapped.
So I am lost, what does /proc/self/fd do with
all that?


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

If alone - yes.
But when you have multiple mappings, one of
which is still at reloc_address, then things
magically start to work again.
Probably you still haven't realized the whole
power of la_premap_dlmem(). Please note that
la_premap_dlmem() is not the same as la_premap().
These are different extensions, but when they
play together, that can do Real Things (TM).


> AFAICT these discussions are all solved by memfd_create. Almost all of the
> complaints revolve around the memory vs. disk performance difference,

I am getting a bit nervous already when people
mention memfd_create(). :) In what way is it
any better than shm_open(), that I used in my
la_premap_dlmem() example?
Yes, I could also use memfd_create() with
la_premap_dlmem(), but I prefer shm_open().
Why people think that memfd_create() is the
thing, is unclear to me. :) But it fits my
design very well, as does shm_open().


> memfd_create is a very easy way to get a memory-backed file on modern Linux
> boxes.

... and provide it to la_premap_dlmem().
But I'll use shm_open! :)


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

Well, I am not saying these examples
deserve much of an attention. But I used
them to bring up an API that at least is
requested multiple times, and layer the
rest on top. The warning here is the next
time you'll deal with much more alien and
complicated API that won't solve the entire
task even. So why not to use mine, its was
requested multiple times, its written, it
will be proven (within this thread) to solve
the stated task, and very unlikely some hack
can be proposed as an alternative.

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