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

[nisse at lysator dot liu dot se (Niels MÃller)]

"Carlos O'Donell" <carlos@systemhalted.org> writes:

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

Thanks for the answer. That makes ifunc a bit difficult to use... Maybe
I need to disable its use until the API is improved. 

I use it on x86_64 and ARM. On both platforms, I really want to have an
environment variable to override the resolver's automatic selection, so
I have to call getenv. And on ARM, I also call fopen, for reading
/proc/cpuinfo. I think it really ought to be possible to call functions
from other .so files, in particular libc, which the current one depends
on.

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

That doesn't seem to happen (but I haven't yet tried to reproduce the
problem myself).

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

I think it would make a lot of sense to make sure that all non-ifunc
relocations are valid (either completely resolved, or set up the same
way as for RTLD_LAZY), before calling any ifunc resolvers. Is that
doable? Then it would be safe to call into libc, as well as any
non-ifunc symbols in the library being loaded.

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

Not sure why this doesn't appear to happen. Is there some way to invoke
ld.so (or set some environment variable) do get some debug output as
each symbol is processed?

> Do you have a test case you can provide?

I'll try to reproduce. Or maybe Mark can tell you how to reproduce it?

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

One way could be to pass to the ifunc resolver function a pointer to
dlsym (or some variant thereof, without the handle argument). To let the
ifunc resolver lookup any symbols it needs without going through the
PLT. (But I think that's going to be more brittle than delaying these
relocation and doing them last).

Regards,
/Niels

-- 
Niels MÃller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.