Re: Detecting multiple libcs

[Florian Weimer <fweimer at redhat dot com>]

On 06/03/2016 06:50 PM, Carlos O'Donell wrote:
> On 06/03/2016 10:50 AM, Florian Weimer wrote:
> > ptmalloc_init has this code:
> >
> > #ifdef SHARED
> >   /* In case this libc copy is in a non-default namespace, never use brk.
> >      Likewise if dlopened from statically linked program.  */
> >   Dl_info di;
> >   struct link_map *l;
> >
> >   if (_dl_open_hook != NULL
> >       || (_dl_addr (ptmalloc_init, &di, &l, NULL) != 0
> >           && l->l_ns != LM_ID_BASE))
> >     __morecore = __failing_morecore;
> > #endif
> >
> > But it does not seem t work because after a static dlopen, _dl_open_hook is NULL.
>
> Just to be clear, you have verified that the value of _dl_open_hook is NULL
> for the copy of that variable in the newly loaded library?

I thought I had.  I'm no longer sure.  The test case passes now.  I 
probably had botched something along the way.

__libc_multiple_libcs is 0, though (although gdb prints 1 because it 
uses the variable in the outer namespace).

We have a larger problem, though:

(gdb) info symb &_dl_open_hook
_dl_open_hook in section .bss of /lib64/libc.so.6

(This is from a regular dynamically linked executable.)
This pointer variable should really be in the .relro section.

The existing patching mechanism for static dlopen uses a dlsym lookup in 
the new namespace, and just patches in the intended value (with 
_dl_open_hook and _dlfcn_hook).  It would be nice to have these pointers 
in .relro instead, but that needs significant changes.  With the current 
approach, it seems that the patching happens really late, after ELF 
constructors from the new DSOs have already run.

Does the above seem more reasonable?  (I'm apparently quite confused today.)

As a stop-gap measure, we could mangle the hook pointers.  The pointer 
guard value is derived from AT_RANDOM on both sides of the linking 
barrier, so the mangling will be identical.

Florian