[Bug dynamic-link/21041] IFUNC setjmp/longjmp in libpthread.so are unsafe

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21041

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #15 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #14)
> Created attachment 9776 [details]
> Patch to remove compatibility symbols from libpthread
> 
> (In reply to H.J. Lu from comment #13)
> > (In reply to Florian Weimer from comment #12)
> > > (In reply to H.J. Lu from comment #10)
> > > > Can we simply remove setjmp/longjmp from libpthread.so?
> > > 
> > > I tried this before, but it does not work with the current dynamic linker:
> > > 
> > >   https://sourceware.org/ml/libc-alpha/2016-05/msg00176.html
> > > 
> > > I never received a clarification if this behavior is required, or a dynamic
> > > linker bug.
> > 
> > Do you have a testcase?
> 
> Compile glibc with the attached patch and install it.  The system will no
> longer boot because of errors like this one:
> 
> # /sbin/init
> /sbin/init: relocation error: /usr/lib/systemd/libsystemd-shared-232.so:
> symbol write, version GLIBC_2.2.5 not defined in file libpthread.so.0 with
> link time reference
> 
> I'm not sure if this link failure is a dynamic linker bug.  The symbol
> versioning specification is ambiguous whether the soname in the version
> counts for symbol resolution.

I've always wondered about this, and the truth is I consider the binding we
have today to be overspecified.

I think that any write@@GLIBC_2.2.5 should be able to resolve
write@GLIBC_2.2.5, not just he one that came from the library that provided the
original link-time reference (encoded in .gnu.version_r).

However, Ulrich's original design seems to explicitly call this out:
~~~
This has to be done by walking through all the entries of the loading
object's Elfxx_Verneed array and examining whether the loaded object's
Elfxx_Verdef array contains an appropriate version definition.  Both,
the version definition and the version requirement, are identified by
strings.  In both cases the structures contain beside the string (or
string references) also ELF hashing values which can be compared
before making the actual string comparison.
~~~

So there is an implicit binding of <symbol> + <version> to <soname> that
happens.

The only rationale given is:
~~~
This way it is possible to recognize libraries which
are too old and don't contain all the symbols or contain incompatible
implementations.  Without this kind of test one could end up with
runtime errors which don't provide helpful information.
~~~

It also means you can never move the versioned symbol to another shared object.

-- 
You are receiving this mail because:
You are on the CC list for the bug.