[Bug libc/28487] Static application fault with dlopen library in rtld_malloc stubs

["Houdek.Ryan@fex-emu.org" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #2 from Ryan Houdek <Houdek.Ryan@fex-emu.org> ---
This application can't be fully dynamic because it needs to support
binfmt_misc.
This application will be used in cross-arch chroot environments and runtime
executable dynamic loader executable environment at the same time.

In the cross-arch chroot environment, dynamic libraries (likely, more on that
in a moment) won't be used.
We don't want, and in some edge cases, can't provide the host architecture's
libraries to be available inside of the chroot.
binfmt_misc will load the interpreter for each process in this instance.
We can't provide the host architecture's libraries in these cases since the
distributions involved may not support multiarch.

In the case of the application being used outside of the cross-arch chroot.
Then the binfmt_misc application will still be picked up for the other
architecture's executables (Think 32-bit x86 being executed on AArch64).
At some point in the application's code path, we will need to load libGL, but
we can't know that up front.

Then in the worst case, we will be in a cross-arch chroot environment, we will
have binded the host architecture's libraries in to the cross-arch chroot.
We will then end up dynamically loading libraries or not depending on a bunch
of tooling being run.

Since binfmt_misc is something that needs to be setup by a root user, we can't
really do much about changing the binary depending on namespace. Doesn't really
matter since in some cases you can't ever preempt what will happen.

If dlopen from static-pie executables is removed then it is very much going to
break behaviour here. It wasn't noticed before but it is now since some of the
scope is expanding.

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