This is the mail archive of the
mailing list for the glibc project.
Re: Harden powerpc64 elf_machine_fixup_plt
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at libc dot org>, Alan Modra <amodra at gmail dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 20 Mar 2015 11:51:55 -0400
- 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>
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.