From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66692 invoked by alias); 20 Jan 2017 18:36:38 -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 57108 invoked by uid 89); 20 Jan 2017 18:36:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-HELO: mail-vk0-f67.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G0qJka8ncOlXogKxOycSz+4xJ+0IcxpY+qxVDBidjzo=; b=I809G85yAUjj1jY2RLvZsc2eBuj91rP3ipJPq5hBJtmHNsoEkGz1vHWbY97WY7XJ3Q 3EBB8om0G1yKbTt4bzzH6nGm8uv4uB2Q1yl8Z0V8Dc1HnIyrPX+aYZTpm6AOzWz11ryN cT9W0trnZzdeYDzYvJwydagPrw5LQ8Via2sfVYTgsZfgYinN6QAvJJdK9AGRphLnwe9m N12g1cILr2IqWuieIvU+urzjNDwULEvB6ceOQTX2/BeIznGmfTHi8M5ktcLUwlWnolkS lS3Hg8UMY4hY10+BqXbIUc7RTmaBANLqXZjVN2plCeponN5ShjZmh7Eknl55/xTGePrK ulIg== X-Gm-Message-State: AIkVDXLI5ISJB4sk1KOqH0gp+S87IelaROHuOLa9c9emeAeILA2W1DxjWMWPNtb+jxnWPwEKvI7elugTNdj71w== X-Received: by 10.31.28.193 with SMTP id c184mr7474808vkc.173.1484937383510; Fri, 20 Jan 2017 10:36:23 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20161004184621.GB27454@intel.com> <00fa4a04-7c02-fe70-7892-3f6f90f733cb@gmail.com> From: Khem Raj Date: Fri, 20 Jan 2017 18:36:00 -0000 Message-ID: Subject: Re: [PATCH 2/2] Add an x86 IFUNC testcase for [BZ #20019] To: "H.J. Lu" Cc: GNU C Library Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2017-01/txt/msg00406.txt.bz2 On Fri, Jan 20, 2017 at 9:00 AM, H.J. Lu wrote: > On Thu, Jan 19, 2017 at 10:42 AM, Khem Raj wrote: >> On Fri, Jan 13, 2017 at 12:15 PM, H.J. Lu wrote: >>> On Fri, Jan 13, 2017 at 11:30 AM, Khem Raj wrote: >>>> >>>> >>>> On 1/13/17 11:03 AM, H.J. Lu wrote: >>>>> On Wed, Oct 12, 2016 at 3:19 PM, H.J. Lu wrote: >>>>>> On Tue, Oct 11, 2016 at 10:45 PM, Carlos O'Donell wrote: >>>>>>> On 10/05/2016 02:16 PM, H.J. Lu wrote: >>>>>>>> On Tue, Oct 4, 2016 at 5:09 PM, Joseph Myers wrote: >>>>>>>>> On Wed, 5 Oct 2016, H.J. Lu wrote: >>>>>>>>> >>>>>>>>>> I can try __builtin_memcpy, instread of __builtin_memmove. There are 2 >>>>>>>> >>>>>>>> I changed it to use __builtin_memset. >>>>>>>> >>>>>>>>>> acceptable results. One is ld.so issues an error and the other is program runs. >>>>>>>>>> On x86, ld.so issues an error. I don't know what should happen on others. >>>>>>>>> >>>>>>>>> You could make the test pass on either of those results (while failing if >>>>>>>>> ld.so crashes). >>>>>>>>> >>>>>>>> >>>>>>>> I moved the test to elf. It passes if the test runs or ld.so issues an >>>>>>>> error. Please try it on arm, powerpc and s390. >>>>>>> >>>>>>> This is the wrong way to test this. >>>>>>> >>>>>>> The point of this test is this: >>>>>>> >>>>>>> - Verify that an unversioned symbol reference in DSO A which has no DT_NEEDED >>>>>>> on DSO B, when resolved to a symbol definition in DSO B, when the symbol in >>>>>>> DSO B is an IFUNC with a resolver, that DSO B is relocated _before_ the IFUNC >>>>>>> resolver is called, because DSO B's resolver might need global data to make >>>>>>> the IFUNC decision e.g. GOT setup. >>>>>>> >>>>>>> The invariant we want to hold true for IFUNC is that to call the resolver >>>>>>> function you must have relocated the DSO which contains the resolver. This _should_ >>>>>>> have been done by a symbol reocation dependency analysis, but that isn't working >>>>>>> correctly IMO or needs deeper analysis in the dynamic loader. >>>>>>> >>>>>>> The solution we want in place today is to issue some kind of diagnostic until we >>>>>>> fix the real problem. >>>>>>> >>>>>>> The test should look like this: >>>>>>> >>>>>>> - DSO A with an unversioned symbol reference to 'foo'. >>>>>>> - DSO B with a symbol definition of 'foo' as an ifunc with 'foo_resolver' as the >>>>>>> resolver function which references global data from DSO C to decide which of >>>>>>> two functions to return. >>>>>>> - DSO C with global data set to a value. >>>>>>> >>>>>>> The point is that DSO B depends on DSO C and has DT_NEEDED on it, so C will get >>>>>>> relocated first, then B, such that B's GOT is setup to access C's global data. >>>>>>> >>>>>>> When handling the reference to 'foo' in DSO A we should on x86_64 and i686 >>>>>>> get the error about needing to relink DSO A so it depends on DSO B, to form >>>>>>> the initialization order of C->B->A. >>>>>>> >>>>>>> I expect this test case will now crash the other arches, rather than just >>>>>>> avoiding the crash by relying on internal libc.so details about which ifuncs >>>>>>> you're using. >>>>>>> >>>>>>> This is one step towards a better definition of IFUNC semantics, which need to >>>>>>> be more clearly defined (something I wish I had time to define and fix so >>>>>>> more projects could use them). >>>>>> >>>>>> IFUNC resolver can fail for various reasons. My goal is to make sure >>>>>> that IFUNC inside of glibc works correctly or an error message is given >>>>>> when glibc isn't used properly. In case of x86, CPU feature info is >>>>>> retrieved and stored in ld.so very early at startup, which is used by IFUNC >>>>>> and only accessible in libc.so and libm.so after they have been relocated. >>>>>> My change in x86 ld.so checks it and my test verifies the check. My fix >>>>>> won't cover other possible IFUNC failures. >>>>>> >>>>> >>>>> When the IFUNC relocation is performed before the providing shared >>>>> library is unrelocated, the returned function address will be 0 and >>>>> program will segfault when the function is called. >>>>> >>>>> Please apply this patch and run the test if your platform has IFUNC. I only >>>>> enabled the unsafe resolver check for i386 and x86-64. It is straightforward >>>>> to add check for other platforms. >>>> >>>> I will test it out shortly. One thing I see, the runner script for test >>>> is calling out for /bin/bash and the script does not use any bash >>>> extentions perhaps using /bin/sh is enough. >>>> >>> >>> Here is the updated patch with some fixes. >> >> This still failed on 32bit in same way. >> > > Did you get segfault? No, I was testing it for https://sourceware.org/bugzilla/show_bug.cgi?id=21041 I am getting same ldso IFUNC messages