rtld: resolve incoming STT_GNU_IFUNC only after DT_INIT

John Reiser jreiser@bitwagon.com
Wed Nov 1 17:57:00 GMT 2017


On 11/01/2017 1724Z, Florian Weimer wrote:
> * John Reiser:
> 
>> However, a relocation from some other module to a STT_GNU_IFUNC symbol
>> in the current shared library cannot be intercepted like that.
>> That's why DT_INIT should be called before such a relocation is resolved,
>> so that the IFUNC code can be de-compressed into the right place
>> before it gets called.
> 
> I don't think it's safe at all to call DT_INIT during relocation
> processing.  You need to explain why you think it is.

If all processing is done in dependency order (thus "B depends on A"
requires that all processing of A occurs before any processing of B;
this includes "B has a relocation that designates a symbol that is
resolved by A with type STT_GNU_IFUNC")
*and* if internal STT_GNU_IFUNC resolution within the same module
is hidden from rtld like I have suggested, then calling the DT_INIT
will be safe.  All the STT_GNU_IFUNC symbols in predecessor modules
in the dependency order will be available, and all the STT_GNU_IFUNC
symbols in the same current module will be specially processed (transformed
into R_*_IRELATIVE by /bin/ld, hidden from rtld by the compressor, and
resolved by DT_INIT as soon as their instructions have been de-compressed
and before any "normal" execution begins.)

> 
> I really don't see how we can make this happen.  As I said, DT_INIT
> may need the relocations which result from IFUNC processing.
> 

If those IFUNC-backed relocations are in predecessor modules (topological
sort of dependencies) then they will have been taken care of already
because *all* processing of predecessors occurs first:

    Process the relocations of module A, call A.DT_INIT.
    Process the relocations of module B, call B.DT_INIT.

If those IFUNC-backed relocations are in the current module
then they will be handled by STT_GNU_IFUNC ==> R_*_IRELATIVE
==> compressor hides from rtld ==> DT_INIT calls IFUNC immediately
after de-compression.

-- 



More information about the Libc-alpha mailing list