Re: Harden powerpc64 elf_machine_fixup_plt

["Carlos O'Donell" <carlos at redhat dot com>]

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.

Cheers,
Carlos.