Harden powerpc64 elf_machine_fixup_plt

[Alan Modra]

On Fri, Mar 20, 2015 at 11:22:45AM -0400, 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.

Yes, that would be unfortunate.  "Don't call non-local functions in an
ifunc resolver" sounds like a good rule.  Certainly for user code,
where you don't know whether an external function may use ifunc (or
might in some future version of a library).

> 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.

Right, that helps, and covers calling a non-local function too.
However, an ifunc resolver must return an address.  Targets that don't
have pc-relative addressing, and don't implement some form of
gp-relative addressing, calculate even local PIC addresses by loading
a GOT entry.  That's the fundamental problem of C ifunc resolvers, and
why I say it is impossible to write ifunc resolvers in C that work in
all situations.

-- 
Alan Modra
Australia Development Lab, IBM