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

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

[Houdek.Ryan@fex-emu.org]

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

            Bug ID: 28487
           Summary: Static application fault with dlopen library in
                    rtld_malloc stubs
           Product: glibc
           Version: 2.33
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: Houdek.Ryan@fex-emu.org
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 13731
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13731&action=edit
Test application.

In some instances when a static/static-pie application does a dlopen on a
shared library, the shared library will attempt to use the rtld_malloc stubs.

These stub symbols are expected to be setup by the original application being
loaded. Since we were a static application, these symbols aren't ever setup for
something that the shared library to see.

A likely workaround is that when the dynamic linker is loaded with the initial
dlopen that `__rtld_malloc_init_real` should be called at some point.

Sadly I'm having a hard time debugging this locally myself so I'm looking for
help.

I have a simple test application that compiles the main application elf as
static-pie, then it loads a dynamic library that creates a thread.
The act of creating a thread tries to use the rtld_malloc symbols.
This was the easiest way I could find something that uses these malloc
routines.
This is attached as source.

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

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

[carlos at redhat dot com]

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
Just a quick note that since glibc 2.27 calling dlopen from a static executable
is deprecated. The intent is to fully support static linkage, but mixed static
and dynamic linkage will not be allowed. So while this works today, and we may
review exactly what happened in this test case, it will certainly not be
supported in the future.

Is there any reason you can't use a fully dynamic link for this application?

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

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

[Houdek.Ryan@fex-emu.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.

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

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #3 from Florian Weimer <fweimer at redhat dot com> ---
The issue here is the attempt to create a thread. This is very difficult to
support from a statically linked executable that has not been linked with
libpthread. Even if the statically linked binary has a sufficiently complete
copy of libpthread.a linked in, it will still need substantial glibc changes to
implement support for this. To be honest, I think we should spent our resources
on other efforts.

The binfmt_misc handler can be a shell script, it does not have to be the final
process running the binary. See Documentation/admin-guide/java.rst for an
example. You should use a shell script or a minimal static executable that
launches the actual interpreter, which can be dynamically linked. Use an
explicit loader invocation if necessary (in case the dynamically linked
interpreter does not have a usable PT_INTERP header for the chroot), and
perhaps adjust environment variables as needed.

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