[prev in list] [next in list] [prev in thread] [next in thread] 

List:       glibc-alpha
Subject:    Re: IFUNC resolver scheduling (bugs 21041, 20019)
From:       Florian Weimer <fweimer () redhat ! com>
Date:       2017-01-29 21:56:50
Message-ID: 7b848fd4-76a8-49f4-45a0-72efbbef9aaf () redhat ! com
[Download RAW message or body]

On 01/28/2017 03:27 AM, Carlos O'Donell wrote:
> On 01/25/2017 08:57 AM, Florian Weimer wrote:
>> I tried to fix most of the issues involving IFUNC resolvers and their access to unrelocated symbols.
> ...
>> Comments?
>
> H.J.'s patch turns a runtime segfault (if the function is ever
> called)

This all about non-lazy binding, so whether the function is called, does 
not matter.  (Even with lazy binding enabled, there are some relocations 
for which lazy binding is not available, so the issue can still happen 
with lazy binding.)

> into a dynamic loader failure message that tells you
> exactly what is wrong.

I do not think this is an accurate characterization of the impact of the 
change.  The breakage it detects cannot always be fixed by relinking.

We need to decide whether IFUNC resolvers can use relocations.  If yes, 
we need something to reorder the relocation processing in a more useful 
way.  The restrictions in H.J.'s patch will no longer be necessary as a 
result.

If no (which is what is currently implied by the wiki page), we need to 
revert H.J.'s patch because the execution order of IFUNC resolvers with 
regard to other relocations does not matter.  But in this case, we need 
to fix glibc to comply with the rules.  I don't see how this is possible 
without chaning the (architecture-specific) IFUNC resolver function 
argument lists (to be able to access architecture-specific information 
without relying on relocations), so it is a somewhat invasive change.

> The segfault scenario has been present since Feb 2015, and thus
> possibly 4 releases.

I think it has been there for much longer than that.  Increased use of 
BIND_NOW just uncovered more problems.

> Revering H.J.'s patch just gets us back to things crashing
> mysteriously at runtime. So I'm not looking to revert the patch.

It also un-breaks programs which comply with the wiki rules on IFUNC 
resolvers.

> The only alternative seems to be to loosen the soname and
> version checks and remove the versioned interposers from
> libpthread? That seems more risky than your change.

I think the soname check only ensures that there is any matching version 
with the soname for the symbol.  Curiously, the versioned symbol can 
still be bound to a definition in any DSO, irrespective of the soname. 
There is only one definition for a symbol/version pair, the soname is 
*not* used as a tie-breaker.

Luckily for us, this should make it fairly safe to drop the soname check 
because it does not alter symbol binding.  More programs will work as a 
result, and we could drop the problematic IFUNC-based redirections in 
libpthread (which is a prerequisite for complying with the wiki IFUNC 
resolver requirements).

(We should also fix the static linker to disregard compat symbols more 
effectively; we shouldn't have bindings to compat functions in 
libpthread at all.)

> Do you think your patch is viable for 2.25 to fix bug 21041?

We don't have a complete patch yet, and I still don't see consensus 
whether we actually want to relax the documented IFUNC resolver 
requirements.  I'm not even sure which direction you prefer. :)  (And I 
haven't made up my mind, either.)

What's worse, the patch changes the architecture-specific parts of the 
dynamic linker and thus (partially) invalidates the release testing done 
os far.

Thanks,
Florian

[prev in list] [next in list] [prev in thread] [next in thread]