From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6290 invoked by alias); 30 Mar 2016 16:47:44 -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 6253 invoked by uid 89); 30 Mar 2016 16:47:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=inability, Hx-languages-length:1775 X-HELO: mx1.redhat.com Subject: Re: Incorrect IFUNC use in libpthread for fork, vfork wrapper [BZ #19861] To: Florian Weimer , GNU C Library References: <56FBD238.1010101@redhat.com> From: Richard Henderson X-Enigmail-Draft-Status: N1110 Message-ID: <56FC032B.6040700@redhat.com> Date: Wed, 30 Mar 2016 16:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FBD238.1010101@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00733.txt.bz2 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. > Is there a reliable test case which exposes this problem? I made the > vfork wrapper in libpthread a non-tail-call, fixed up the nptl vfork > tests to actually call the wrapper (which I assume they currently don't > due to the compat symbol), and still didn't get any crash. If you're talking vfork, then you *must* use a tail-call, or other means (like ifunc) to arrive at the syscall with no stack used. Otherwise you will have situations where the child corrupts the saved return address of the parent. The inability to reliably generate a tail-call between libraries for all ports is exactly why we're defaulting to use an IFUNC in the first place. But certainly individual ports are free to override pt-vfork.c. The simplest way is simply not to bounce to libc at all, but continue to provide a copy of vfork within libpthread. E.g. sysdeps/unix/sysv/linux/alpha/pt-vfork.S. r~