Re: Function calls in my ifunc resolver crash due to unitialized PLT entries.

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Mon, Jun 22, 2015 at 3:22 AM, Niels MÃller <nisse@lysator.liu.se> wrote:
> I'm not sure exactly what an application can do inside a ifunc resolver,
> but I'd expect to at least be able to call libc functions? I have other
> libc calls, including secure_getenv and fprintf (mainly for debug
> purposes).

My apologies. This is a community problem. We have done a terrible job
of documenting exactly what can and can't be done in in the GNU IFUNC
resolvers. The truth is that you do not have any guarantee that you
can call any functions via the PLT. You have have no guarantees that
the relocations to the PLT and GOT have been completed by the time
your resolver runs. Thus documentation today would read "Call only
local static functions using local static or global data." In glibc
proper we are still struggling to define exactly what we can and can't
guarantee. Until we document this in the glibc manual, the use of
IFUNC remains a somewhat "advanced" feature. On x86 and x86_64 only
you have some guarantee that the IRELATIVE reloc, which runs your
resolver function, runs after all PLT and GOT relocs have been
processed, but only on those two machines.

It is nice to see the use of IFUNCs outside of glibc (the only present
use I know of as a glibc developer). It would be good to talk with you
about your use case and see what we can do.

Note this TODO list entry:
https://sourceware.org/glibc/wiki/Development_Todo/Master#Explore_using_STT_GNU_IFUNC_to_support_data-dependent_function_resolvers

Which would resolve some of your problems. If the IRELATIVE relocs
were processed late, then we might get away with calling any function
we wanted, with the usual caveat that DSO dependency loops result in
potentially undefined behaviour (with a new ldd to help you find
those).

> In what order are PLT entries initialized with RTLD_NOW? If all
> non-ifunc entries were done first, that would make things easier for the
> ifunc resolver functions. Or if such ordering is hard to do, first
> initialize all PLT entries in the same way as with RTLD_LAZY, so that
> the first call to _nettle_cpuid or memcmp gets that symbol properly
> resolved.

The IRELATIVE relocations are sorted and processed last on x86 and
x86_64. This ensures that previous PLT and GOT relocs are processed
first.

With RTLD_NOW, the GOT entries (which provide the data to the PLT jump
slots), should be processed and fully resolved before the IRELATIVE
relocs are run.

Do you have a test case you can provide?

Can you file a bug? https://sourceware.org/bugzilla/

> Are there any other ways to tweak the ordering? Can I call back into the
> libc resolver from the my ifunc resolver to request that particular
> symbols are resolved, before I go on and call them?

Not yet, but that would be part of an API that would help us solve this better.

Cheers,
Carlos.