Re: [PATCH 2/2] Add an x86 IFUNC testcase for [BZ #20019]

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Jan 20, 2017 at 10:35 AM, Khem Raj <raj.khem@gmail.com> wrote:
> On Fri, Jan 20, 2017 at 9:00 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Thu, Jan 19, 2017 at 10:42 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Fri, Jan 13, 2017 at 12:15 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Fri, Jan 13, 2017 at 11:30 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>>
>>>>>
>>>>> On 1/13/17 11:03 AM, H.J. Lu wrote:
>>>>>> On Wed, Oct 12, 2016 at 3:19 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>> On Tue, Oct 11, 2016 at 10:45 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>>>>>>>> On 10/05/2016 02:16 PM, H.J. Lu wrote:
>>>>>>>>> On Tue, Oct 4, 2016 at 5:09 PM, Joseph Myers <joseph@codesourcery.com> 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

I updated ld.so for i686 and x86-64 so that ld.so issues an error message,
instead of segfautl. Have you tested it on non-x86 machines?

-- 
H.J.