Re: Are ifuncs intended to be allowed to resolve to symbols in another DSO?

[Carlos O'Donell <codonell at redhat dot com>]

On 2/3/20 3:06 PM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> If an IFUNC resolver calls a function which is not yet resolved then
>> isn't that a defect in the IFUNC resolver?
> 
> There is a position that an IFUNC resolver must not use any non-local
> relocations.  (We must support some relocations for IFUNCs on
> !PI_STATIC_AND_HIDDEN targets.)  In this case, yes, such a dependencies
> would be a bug because all external dependencies are bugs.

Just so I understand the position is, to simplify the implementation, that
IFUNC resolvers must not use any non-local relocations?

What does non-local relocations mean? Are we saying the target of all
relocations must be within the same linkmap as the resolver? Are we saying
then that resolvers can only manipulate local data and make local function
calls?

I don't think that would be useful since you'd want to call many libc functions
from the resolver itself and so you would have calls in the resolver that
could call through a GOT entry that has a relocation against an external
symbol in another DSO e.g. libc.so.6.

If an IFUNC resolver has relocations that against non-local symbols
then those symbols must have been a dependency of the object and listed
in DT_NEEDED and therefore relocated before the current IFUNC resolver
is running.

> On the other hand, in glibc, we could get rid of many IFUNC resolvers
> which violate this rule only after changing the loader that eliminated
> their need for them.  Other IFUNCs that do not follow this rule do not
> have this luxury.

I don't quite parse your first setnence here, could you expand on that please?

When you speak about luxury, you mean to say that IFUNCs in other projects
would not have the same possibility to solve such a problem like we do in
glibc?

>> The code which contains such an IFUNC should have had a DT_NEEDED entry
>> on all objects to which the resolver called into?
> 
> This does not help with symbol interposition.

What exact problem does symbol interposition cause?

>> I like solutions that ensure that IFUNC resolvers, which are just foreign
>> functions, run at a stage *after* their own dependencies have been resolved,
>> but before their own initializers have run.
> 
> Lazy binding achieves this because it implicitly tracks this dependency
> information.  For eager binding, we simply do not have this information.
> Hence my patch for delayed relocation processing.  But it does not solve
> the problem completely, of course.

The dependencies are explicitly tracked by DT_NEEDED.

Then when we have underlinked libraries we try to suppliment this and reorder
by relocation dependencies. This may be causing more problems than it solves?

If we had good visibility into the load order manipulations because of the
relocations I think users would understand the consequences of these problems
and we would also be able to better identify underlinked applications and file
bugs to fix them (if possible).

-- 
Cheers,
Carlos.