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

[H.J. Lu]

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.


H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-an-IFUNC-testcase-for-BZ-20019.patch
Type: text/x-patch
Size: 13423 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20170113/b7750d3f/attachment.bin>