[Bug dynamic-link/24741] New: ld.so should not require that a versioned symbol is always implemented in the same library

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/24741] New: ld.so should not require that a versioned symbol is always implemented in the same library

Martin.Jansa at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24741

            Bug ID: 24741
           Summary: ld.so should not require that a versioned symbol is
                    always implemented in the same library
           Product: glibc
           Version: 2.30
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: fweimer at redhat dot com
  Target Milestone: ---

ld.so currently performs a check which requires that a versioned symbol is
implemented in the same shared object in which it was found at link time.

The error message looks like this:

symbol FUNCTION-NAME, version SYMBOL-VERSION not defined in file DSO-NAME with
link time reference

This check constrains the evolution of shared objects because implementations
cannot be moved to dependent objects.  This check is only applied to versioned
symbols, and therefore versioned symbols are less powerful than unversioned
symbols in this context.

The presence of this check requires that we add wrapper functions each time we
move a function from a secondary library into libc.so.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/24741] ld.so should not require that a versioned symbol is always implemented in the same library

Martin.Jansa at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24741

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at sourceware dot org   |fweimer at redhat dot com

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/24741] ld.so should not require that a versioned symbol is always implemented in the same library

Martin.Jansa at gmail dot com
In reply to this post by Martin.Jansa at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24741

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Florian Weimer <[hidden email]>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f0b2132b35248c1f4a80f62a2c38cddcc802aa8c

commit f0b2132b35248c1f4a80f62a2c38cddcc802aa8c
Author: Florian Weimer <[hidden email]>
Date:   Fri Jun 28 10:12:50 2019 +0200

    ld.so: Support moving versioned symbols between sonames [BZ #24741]

    This change should be fully backwards-compatible because the old
    code aborted the load if a soname mismatch was encountered
    (instead of searching further for a matching symbol).  This means
    that no different symbols are found.

    The soname check was explicitly disabled for the skip_map != NULL
    case.  However, this only happens with dl(v)sym and RTLD_NEXT,
    and those lookups do not come with a verneed entry that could be used
    for the check.

    The error check was already explicitly disabled for the skip_map !=
    NULL case, that is, when dl(v)sym was called with RTLD_NEXT.  But
    _dl_vsym always sets filename in the struct r_found_version argument
    to NULL, so the check was not active anyway.  This means that
    symbol lookup results for the skip_map != NULL case do not change,
    either.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/24741] ld.so should not require that a versioned symbol is always implemented in the same library

Martin.Jansa at gmail dot com
In reply to this post by Martin.Jansa at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24741

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.30
              Flags|                            |security-

--- Comment #2 from Florian Weimer <fweimer at redhat dot com> ---
Fixed in glibc 2.30.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/24741] ld.so should not require that a versioned symbol is always implemented in the same library

Martin.Jansa at gmail dot com
In reply to this post by Martin.Jansa at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24741

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |20188


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=20188
[Bug 20188] libpthread IFUNC resolver for vfork can lead to crash
--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/24741] ld.so should not require that a versioned symbol is always implemented in the same library

Martin.Jansa at gmail dot com
In reply to this post by Martin.Jansa at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24741

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Florian Weimer <[hidden email]>:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=41d6f74e6cb6a92ab428c11ee1e408b2a16aa1b0

commit 41d6f74e6cb6a92ab428c11ee1e408b2a16aa1b0
Author: Florian Weimer <[hidden email]>
Date:   Tue Jul 2 15:12:20 2019 +0200

    nptl: Remove vfork IFUNC-based forwarder from libpthread [BZ #20188]

    With commit f0b2132b35248c1f4a80f62a2c38cddcc802aa8c ("ld.so:
    Support moving versioned symbols between sonames [BZ #24741]"), the
    dynamic linker will find the definition of vfork in libc and binds
    a vfork reference to that symbol, even if the soname in the version
    reference says that the symbol should be located in libpthread.

    As a result, the forwarder (whether it's IFUNC-based or a duplicate
    of the libc implementation) is no longer necessary.

    On older architectures, a placeholder symbol is required, to make sure
    that the GLIBC_2.1.2 symbol version does not go away, or is turned in
    to a weak symbol definition by the link editor.  (The symbol version
    needs to preserved so that the symbol coverage check in
    elf/dl-version.c does not fail for old binaries.)

    mips32 is an outlier: It defined __vfork@@GLIBC_2.2, but the
    baseline is GLIBC_2.0.  Since there are other @@GLIBC_2.2 symbols,
    the placeholder symbol is not needed there.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug dynamic-link/24741] ld.so should not require that a versioned symbol is always implemented in the same library

Martin.Jansa at gmail dot com
In reply to this post by Martin.Jansa at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=24741

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |20220


Referenced Bugs:

https://sourceware.org/bugzilla/show_bug.cgi?id=20220
[Bug 20220] New recvmsg wrapper in 2.24 missing from libpthread
--
You are receiving this mail because:
You are on the CC list for the bug.