Re: Incorrect IFUNC use in libpthread for fork, vfork wrapper [BZ #19861]

[Szabolcs Nagy <nsz at port70 dot net>]

* Richard Henderson <rth@redhat.com> [2016-03-30 09:47:39 -0700]:
> On 03/30/2016 06:18 AM, Florian Weimer wrote:
> > The IFUNC use is incorrect because you cannot assume that some other
> > symbol has been relocated, and the current implementation sometimes
> > returns an unrelocated address.  (The bug is about vfork, but I'm sure
> > fork has the same issue.)
> 
> You should be able to rely on relocations within library A having been run
> before ifunc use within library A.  Anything else is probably a linker/loader bug.
> 
> There are complex situations in which an IFUNC in library A references a symbol
> X within library B, and the data structures behind X have not been relocated.
> 
> But that is not the case here: The reference to __libc_fork within libpthread
> should be resolved by ld.so to the location within libc during primary
> (non-lazy) relocation processing, before entry to main.
> 

the crash happens before entry to main.

libdofork.so has a GLOB_DAT relocation against fork,
so when it is loaded it runs the ifunc resolver
defined in libpthread.so

(the easy way to get that is to use
void *volatile p = (void*)fork;
but -Wl,-z,now works too.)

if the relocations of libpthread.so are processed later
than the relocations of libdofork.so then this can crash.

i'm not sure about the ordering requirements of
relocations of modules.. i think this is only observable
through ifunc resolution.
(e.g. elf defines symbol lookup and ctor ordering but
not relocation ordering across modules.)