This is the mail archive of the
mailing list for the glibc project.
Re: Harden powerpc64 elf_machine_fixup_plt
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Rich Felker <dalias at libc dot org>, Alan Modra <amodra at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 20 Mar 2015 08:58:12 -0700
- Subject: Re: Harden powerpc64 elf_machine_fixup_plt
- Authentication-results: sourceware.org; auth=none
- References: <20150319235208 dot GB26234 at bubble dot grove dot modra dot org> <20150320152245 dot GJ23507 at brightrain dot aerifal dot cx> <550C421B dot 9080305 at redhat dot com>
On Fri, Mar 20, 2015 at 8:51 AM, Carlos O'Donell <firstname.lastname@example.org> 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
>> 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:
I can update IFUNC spec in x86 and x86-64 psABIs. Any feedbacks
are more than welcome. You can send your comments to