Re: Harden powerpc64 elf_machine_fixup_plt

[Rich Felker <dalias at libc dot org>]

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.

Rich