[Bug dynamic-link/14932] dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with versioned "foo"

[Bug dynamic-link/14932] dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with versioned "foo"

[jsm28 at gcc dot gnu.org]

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

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libc                        |dynamic-link

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

[Bug dynamic-link/14932] dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with versioned "foo"

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

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

[Bug dynamic-link/14932] dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with versioned "foo"

[carlos at redhat dot com]

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

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

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

--- Comment #1 from Carlos O'Donell <carlos at redhat dot com> ---
Worse is that dlsym for a symbol that has no default returns NULL, for example
in the case of libpthread.so and you must then use dlvsym to get the symbol.

I agree this should be fixed and dlsym should behave like the application would
normally behave had it just been compiled. You get the default version of the
symbol and RTLD_NEXT gives you the next version and so on.

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

[Bug dynamic-link/14932] dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with versioned "foo"

[i at maskray dot me]

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

Fangrui Song <i at maskray dot me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |i at maskray dot me

--- Comment #3 from Fangrui Song <i at maskray dot me> ---
I just saw a compiler-rt patch which wants to change a dlsym call to dlvsym
because of this: https://reviews.llvm.org/D96348

> COMMON_INTERCEPT_FUNCTION_GLIBC_VER(regexec, "GLIBC_2.3.4");

Due to how the code is organized (it is difficult to inspect the default
version name when compiling), compiler-rt will need to be follow glibc default
version names more closely, which is undesired.

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

[Bug dynamic-link/14932] dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with versioned "foo"

[jakub at redhat dot com]

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

Jakub Jelinek <jakub at redhat dot com> changed:

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

--- Comment #4 from Jakub Jelinek <jakub at redhat dot com> ---
I think changing this is highly undesirable, as written in
https://marc.info/?l=glibc-alpha&m=98313802001691&w=2
the current dlsym behavior provides ABI stability, no matter what you run the
program against it will always return the same symbol.
While if it returns the default symbol (there doesn't need to be any), it would
change behavior depending on what glibc is used at runtime.
Say, you compile/link your program against glibc 2.5, which provides foobar
symbol say at @@GLIBC_2.5, later glibc 2.37 comes and will have
foobar @GLIBC_2.5 and @@GLIBC_2.37.  Some versioned symbols are solely about
adding features while keeping the ABI the same, say it handles another bitmask
in argument that was previously rejected with -1/setting errno or similar, say
regexec, that perhaps can be handled.  But in other cases the ABI of the
function changes, adds/removes argument or e.g. what some argument points to
changes layout (and not just in glibc, but in any versioned shared library).
You really don't want your old programs to suddenly break because of that.

Basically, dlsym should follow what happens when you link against a shared
library before symbol versioning has been added to it (e.g. very old glibc).

sanitizers need to be fixed so that the sanitizer libraries are also symbol
versioned and when they wrap some glibc symbols, they follow the versioning
there, i.e. if they wrap regexec and regexec is on a particular architecture
regexec@GLIBC_2.2.5 and regexec@@GLIBC_2.3.4, then it wraps both of them
and each of those uses dlvsym to find the corresponding symbol in glibc.

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

[Bug dynamic-link/14932] dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with versioned "foo"

[fweimer at redhat dot com]

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

--- Comment #5 from Florian Weimer <fweimer at redhat dot com> ---
Alternatively, we could add a sanitizer-enabled build of glibc, similarly to
what we have for profiling mode today, so that the need for interceptors goes
away completely.

(This is slightly different from building most of glibc with sanitizers
enabled.)

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

[Bug dynamic-link/14932] dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with versioned "foo"

[ppluzhnikov at google dot com]

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

--- Comment #6 from Paul Pluzhnikov <ppluzhnikov at google dot com> ---
(In reply to Jakub Jelinek from comment #4)

> the current dlsym behavior provides ABI stability, no matter what you run
> the program against it will always return the same symbol.

This bug is about "dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo")".

Shouldn't they _both_ provide the same ABI stability (and therefore the _same_
answer)?

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

[Bug dynamic-link/14932] dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with versioned "foo"

[i at maskray dot me]

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

--- Comment #7 from Fangrui Song <i at maskray dot me> ---
The issue is that dlsym(RTLD_DEFAULT, ...) sets flags to
DL_LOOKUP_RETURN_NEWEST (along with one or two other bits) while
dlsym(RTLD_NEXT, ...) passes flags==0 to dl_lookup_symbol_x.
When DL_LOOKUP_RETURN_NEWEST is in action, the default version definition is
preferred over a non-default version definition.

The following patch will make dlsym(RTLD_NEXT, ...) use DL_LOOKUP_RETURN_NEWEST
and therefore fix the bug:

--- i/elf/dl-sym.c
+++ w/elf/dl-sym.c
@@ -144,7 +144,7 @@ RTLD_NEXT used in code not dynamically loaded"));
        l = l->l_loader;

       result = GLRO(dl_lookup_symbol_x) (name, match, &ref, l->l_local_scope,
-                                        vers, 0, 0, match);
+                                        vers, 0, flags, match);
     }
   else
     {

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

[Bug dynamic-link/14932] dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with versioned "foo"

[i at maskray dot me]

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

--- Comment #8 from Fangrui Song <i at maskray dot me> ---
Fixed by
https://sourceware.org/git/?p=glibc.git;a=commit;h=efa7936e4c91b1c260d03614bb26858fbb8a0204
("dlsym: Make RTLD_NEXT prefer default version definition [BZ #14932]")

(I don't have permission to change the status to fixed.)

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

[Bug dynamic-link/14932] dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with versioned "foo"

[i at maskray dot me]

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

Fangrui Song <i at maskray dot me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Assignee|unassigned at sourceware dot org   |i at maskray dot me
   Target Milestone|---                         |2.36
         Resolution|---                         |FIXED

--- Comment #9 from Fangrui Song <i at maskray dot me> ---
(Wow, looks like I got bug edit permission now)

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