From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1355 invoked by alias); 30 Mar 2016 19:10:54 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 1313 invoked by uid 89); 30 Mar 2016 19:10:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1587, ctor, H*r:1002 X-HELO: port70.net Date: Wed, 30 Mar 2016 19:10:00 -0000 From: Szabolcs Nagy To: Richard Henderson Cc: Florian Weimer , GNU C Library Subject: Re: Incorrect IFUNC use in libpthread for fork, vfork wrapper [BZ #19861] Message-ID: <20160330191045.GN9862@port70.net> References: <56FBD238.1010101@redhat.com> <56FC032B.6040700@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56FC032B.6040700@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-03/txt/msg00741.txt.bz2 * Richard Henderson [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.)