Re: What is the purpose of _dl_starting_up and why is it removed for HAVE_INLINED_SYSCALLS?

[Florian Weimer <fweimer at redhat dot com>]

* Carlos O'Donell:

> The question I have is: What does HAVE_INLINED_SYSCALLS have
> to do with the purpose of _dl_starting_up?

I think this part has already been explained.

> In libc _dl_starting_up is used to set __libc_multiple_libc's
> and that makes sense, if we're starting up then we're the only
> libc, otherwise maybe not.

The current implementation of __libc_multiple_libcs is buggy in several
ways, and the Fedora patch appears to fix that:

  <https://sourceware.org/ml/libc-help/2019-06/msg00026.html>

(Discussion continues in July.)

What seems to happen: The state csu/init-first.c:_init sees in an inner
libc created by dlmopen from an LD_PRELOAD object (in an ELF
constructor) is indistinguishable from the state _init sees in the main
libc, so __libc_multiple_libcs ends up being zero.  printf debugging
confirms that.

I thought that the Fedora patch would fix that:

<https://src.fedoraproject.org/rpms/glibc/blob/f30/f/glibc-fedora-__libc_multiple_libcs.patch>

But upon investigation, I can't see why, and trying the patch with an
explicit loader invocation results in the same crash.  I think it will
fix __libc_multiple_libcs for simple cases, though.

As a proper fix, I think we should rename the variables involved, to
make their purpose absolutely clear, and we also need to change dlmopen
to update the state, so that the next loaded libc recognizes that it is
an inner libc, even when this happens during the first execution of ELF
constructors in the process.  We cannot do this from libc's _init
because in corner cases, the function may not run before the problematic
dlmopen call.

We will probably need two different variables, one for “this is an outer
libc” (i.e. not one loaded via dlmopen or static dlopen, so always true
for the static libc), and another one for “the process has multiple
libcs” (which is true if the process has loaded audit modules, called
dlmopen, or performed static dlopen).  The rtld_active function should
stay because it uses GLRO and is therefore harder to spoof (the other
variables will have to reside in read-write memory).

Thanks,
Florian