This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Removing longjmp error handling from the dynamic loader
On 12/03/2019 10:30, Florian Weimer wrote:
> * Rich Felker:
>> Missing symbols at dlopen time with RTLD_NOW or DT_BINDNOW or whatever
>> should never crash the application, but should report the error. With
>> ifunc, I think (?) you have the possibility that the ifunc resolver
>> code will call another function in the library being loaded (or one of
>> its deps) via a plt slot that hasn't yet been initialized, because
>> there's no way to know a dependency order for the relocations to avoid
>> this.
>
> We perform relocations in topological order, and IRELATIVE relocations
> are sorted last by current binutils. So in the absence of cyclic
> dependencies (perhaps as the result of symbol interposition), IFUNC
> resolvers will not encounter uninitialized PLT slots.
IRELATIVE is sorted after JUMP_SLOT
but GLOB_DAT and ABS come before and those can be against an
STT_GNU_IFUNC symbol that is defined in the same module, so
ifunc resolvers can encounter uninitialized PLT slots (no
cyclic dependency needed, with or without bind now).
> IFUNC resolver. It also cannot support cases where an IFUNC resolver
> depends on ELF constructors having run for one of its dependencies
> (which some people did, until distributions started building with
> BIND_NOW).
depending on ctor in ifunc sounds broken.
(i know at least x86 gcc libatomic did this, but that was a bug)
>> But maybe the relocations can just be ordered such that this isn't a
>> concern (by checking all symbolic references prior to doing any ifunc
>> resolvers?).
>
> I think doing that would be excessive and it wouldn't cover the case
> where the IFUNC resolver actually relies on lazy binding for choosing
> the implementation (which could be constructed as valid if IFUNC
> resolvers may rely on relocations).
depending on lazy binding sounds fragile.