Re: Harden powerpc64 elf_machine_fixup_plt

[Mike Frysinger <vapier at gentoo dot org>]

On 20 Mar 2015 08:58, H.J. Lu wrote:
> On Fri, Mar 20, 2015 at 8:51 AM, Carlos O'Donell 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
> >>> 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.
> >
> 
> IFUNC is processor specific. I have some old docs for x86 IFUNC:

the relocs might be, but that doesn't mean the overall process/ABI contract is.  
it's crazy that the same C code might work/not work depending on the CPU/C lib.
-mike

Attachment: signature.asc
Description: Digital signature