This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Harden powerpc64 elf_machine_fixup_plt


On Fri, Mar 20, 2015 at 8:51 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 03/20/2015 11:22 AM, Rich Felker wrote:
>> On Fri, Mar 20, 2015 at 10:22:08AM +1030, Alan Modra wrote:
>>> IFUNC is difficult to correctly implement on any target needing a GOT
>>> to support position independent code, due to the dependency on order
>>> of dynamic relocations.  ld.so should be changed to apply IFUNC
>>> relocations last, globally, because without that it is actually
>>> impossible to write an IFUNC resolver in C that works in all
>>> situations.
>>
>> There are still all sorts of issues with IFUNC resolvers in terms of
>> what they can safely do. I appreciate efforts to improve the current
>> practical situation, but I don't think we can lay the issue to rest
>> until there's a proper specification for what IFUNC resolvers can do.
>> For example even with your ordering requirement, things would still
>> break if one IFUNC resolver ends up referencing another function that
>> happens to be resolved via IFUNC.
>>
>> My preference would be to specify that the IFUNC resolver cannot
>> access any external-linkage symbols (except possibly with hidden
>> visibility) or objects with static storage duration. This would be
>> suitable for resolvers which can obtain a result purely based on cpu
>> probing (in inline asm), but would not work if AT_HWCAP or similar is
>> needed. A slightly less restrictive option would be to permit access
>> to a (possibly target-specific) list of external symbols/static
>> objects. But I don't know whether this would be sufficient to meet the
>> needs of existing IFUNC users.
>>
>> This is really a huge mess -- the fact that a feature like this was
>> allowed to get "out in the wild" with no clear contract for how it
>> works, leaving us stuck with a mess of difficult-to-meet
>> implementation constraints that aren't even clear.
>
> In complete agreement.
>
> Unfortunately no core developer wants to step up and fix this, and
> thus it remains a poorly understood and difficult to use feature.
>

IFUNC is processor specific. I have some old docs for x86 IFUNC:

https://sites.google.com/site/x32abi/documents/ifunc.txt?attredirects=0&d=1

I can update IFUNC spec in x86 and x86-64 psABIs.  Any feedbacks
are more than welcome.  You can send your comments to

https://groups.google.com/forum/#!forum/x86-64-abi

Thanks.

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]