[Bug dynamic-link/19178] New: ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA conflict

[Bug dynamic-link/19178] New: ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA conflict

[hjl.tools at gmail dot com]

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

            Bug ID: 19178
           Summary: ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA conflict
           Product: glibc
           Version: 2.22
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

sysdeps/generic/ldsodefs.h has

#define ELF_RTYPE_CLASS_PLT 1
#ifndef DL_NO_COPY_RELOCS
# define ELF_RTYPE_CLASS_COPY 2
#else
# define ELF_RTYPE_CLASS_COPY 0
#endif
/* If DL_EXTERN_PROTECTED_DATA is defined, address of protected data
   defined in the shared library may be external, i.e., due to copy
   relocation.   */
#ifdef DL_EXTERN_PROTECTED_DATA
# define ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA 4
#else
# define ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA 0
#endif

and _dl_debug_bindings in elf/dl-lookup.c has

      if (value->s)
        {
          if (__glibc_unlikely (ELFW(ST_TYPE) (value->s->st_info)
                                == STT_TLS))
            type_class = 4;
          else if (__glibc_unlikely (ELFW(ST_TYPE) (value->s->st_info)
                                     == STT_GNU_IFUNC))
            type_class |= 8;
        }

      if (conflict
          || GLRO(dl_trace_prelink_map) == undef_map
          || GLRO(dl_trace_prelink_map) == NULL
          || type_class >= 4)
        {

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

[Bug dynamic-link/19178] ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA conflict

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, hjl/pr19178/master has been created
        at  6ecf7e3fafbadcd6e8d9dcb9d115e47f4d7868fb (commit)

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=6ecf7e3fafbadcd6e8d9dcb9d115e47f4d7868fb

commit 6ecf7e3fafbadcd6e8d9dcb9d115e47f4d7868fb
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Wed Oct 28 04:43:26 2015 -0700

    Define ELF_RTYPE_CLASS_TLS/ELF_RTYPE_CLASS_IFUNC

    _dl_debug_bindings updates relocation type class with 4 and 8.  But
    ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA may be defined to 4.  This patch
    adds ELF_RTYPE_CLASS_TLS/ELF_RTYPE_CLASS_IFUNC and use them in
    _dl_debug_bindings.

        [BZ #19178]
        * dl-lookup.c (_dl_debug_bindings): Replace 4 and 8 with
        ELF_RTYPE_CLASS_TLS and ELF_RTYPE_CLASS_IFUNC.
        * sysdeps/generic/ldsodefs.h (ELF_RTYPE_CLASS_TLS): New.
        (ELF_RTYPE_CLASS_IFUNC): Likewise.

-----------------------------------------------------------------------

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

[Bug dynamic-link/19178] ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA conflict

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
Apparently, prelink does

 argv[i] = NULL;
  envp[0] = "LD_TRACE_LOADED_OBJECTS=1";
  envp[1] = "LD_BIND_NOW=1";
  p = alloca (sizeof "LD_TRACE_PRELINKING=" + strlen (info->ent->filename));
  strcpy (stpcpy (p, "LD_TRACE_PRELINKING="), info->ent->filename);
  envp[2] = p;
  envp[3] = NULL;

  ret = 2;
  f = execve_open (dl, (char * const *)argv, (char * const *)envp);
  if (f == NULL)
    {
      error (0, errno, "%s: Could not trace symbol resolving",
             info->ent->filename);
      return 0;
    }

to get relocation type from ld.so and has

#define RTYPE_CLASS_VALID       8
#define RTYPE_CLASS_PLT         (8|1)
#define RTYPE_CLASS_COPY        (8|2)
#define RTYPE_CLASS_TLS         (8|4)

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

[Bug dynamic-link/19178] ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA conflict

[mark.hatle at windriver dot com]

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

Mark Hatle <mark.hatle at windriver dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark.hatle at windriver dot com

--- Comment #3 from Mark Hatle <mark.hatle at windriver dot com> ---
The interface between glibc's rtld (ld.so) and prelink is determined by the
setting of the LD_TRACE_PRELINKING option.  This option in turn sets:

GLRO_dl_debug_mask |= DL_DEBUG_PRELINK

as well as defines the GLRO(dl_trace_prelink_map).

Since the thing that matters in this case is that both the prelinker and glibc
agree on the common values for the 'type_class' field.  It may be reasonable to
do a conversion if DL_DEBUG_PRELINK is enabled to matching prelink values.

This would permit the same values to be used in both older and newer prelink.


The alternative is to do something like:

#define ELF_RTYPE_CLASS_PLT                    1
#define ELF_RTYPE_CLASS_COPY                   2
#define ELF_RTYPE_CLASS_TLS                    4
#define ELF_RTYPE_CLASS_IFUNC                  8
#define ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA  16 (was 4)

This would preserve previous behavior (glibc 2.21 and before) and add the new
type as '16'.

I do not know though if this is "ok", in that the users of
ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA inside of glibc itself could be affected.
 If this value is used internally -- it shouldn't cause any problems, otherwise
we've got the potential issue of other things not understanding the value was
changed.

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

[Bug dynamic-link/19178] ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA conflict

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 8754
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8754&action=edit
A patch

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

[Bug dynamic-link/19178] ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA confuses prelink

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ELF_RTYPE_CLASS_EXTERN_PROT |ELF_RTYPE_CLASS_EXTERN_PROT
                   |ECTED_DATA conflict         |ECTED_DATA confuses prelink

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

[Bug dynamic-link/19178] ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA confuses prelink

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #8754|0                           |1
        is obsolete|                            |

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 8755
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8755&action=edit
A new patch

Please try this one.

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

[Bug dynamic-link/19178] ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA confuses prelink

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, hjl/pr19178/master has been created
        at  d8952eb0d100475c74c5f282ac32519389ee3e0c (commit)

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=d8952eb0d100475c74c5f282ac32519389ee3e0c

commit d8952eb0d100475c74c5f282ac32519389ee3e0c
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Wed Oct 28 07:49:44 2015 -0700

    Clear ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA for prelink

    prelink runs ld.so with the environment variable LD_TRACE_PRELINKING
    set to dump the relocation type class from _dl_debug_bindings.  prelink
    has the following relocation type classes:

    where ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has a conflict with
    RTYPE_CLASS_TLS.

    Since prelink doesn't use ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, we
    should clear the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA bit when the
    DL_DEBUG_PRELINK bit is set.

        [BZ #19178]
        * elf/dl-lookup.c (RTYPE_CLASS_VALID): New.
        (RTYPE_CLASS_PLT): Likewise.
        (RTYPE_CLASS_COPY): Likewise.
        (RTYPE_CLASS_TLS): Likewise.
        (_dl_debug_bindings): Use RTYPE_CLASS_TLS and RTYPE_CLASS_VALID
        to set relocation type class for DL_DEBUG_PRELINK.  Clear the
        ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA bit for DL_DEBUG_PRELINK.

-----------------------------------------------------------------------

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

[Bug dynamic-link/19178] ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA confuses prelink

[mark.hatle at windriver dot com]

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

--- Comment #7 from Mark Hatle <mark.hatle at windriver dot com> ---
I think the logic in the patch isn't quite right.

        {
          if (__glibc_unlikely (ELFW(ST_TYPE) (value->s->st_info)
                                == STT_TLS))
-           type_class = 4;
+           type_class = (RTYPE_CLASS_TLS & ~RTYPE_CLASS_VALID);
          else if (__glibc_unlikely (ELFW(ST_TYPE) (value->s->st_info)
                                     == STT_GNU_IFUNC))
-           type_class |= 8;
+           {
+             type_class |= RTYPE_CLASS_VALID;
+           }
+         /* Clear the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA bit since
+            it isn't used by prelink.  */
+         type_class &=
~ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA(undef_map->machine);
        }

With this change, I was able to verify that the ld.so results from 2.21 and
2.22 are producing the same values for me now.

Otherwise, most of the previous '0' values have been replaced with '4'.

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

[Bug dynamic-link/19178] ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA confuses prelink

[mark.hatle at windriver dot com]

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

--- Comment #8 from Mark Hatle <mark.hatle at windriver dot com> ---
What I pasted still isn't correct.  It's clearing the '4' that should be on the
TLS values.

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

[Bug dynamic-link/19178] ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA confuses prelink

[mark.hatle at windriver dot com]

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

--- Comment #9 from Mark Hatle <mark.hatle at windriver dot com> ---
Created attachment 8756
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8756&action=edit
Revised version of HJ Lu's patch

The patch attached is working for me.

Moving the filtering of the EXTERN_PROTECTED_DATA before the other fixups
ensures that it is always filtered first.  We can then add the value of '4' for
TLS and |= 8 (valid) as necessary.

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

[Bug dynamic-link/19178] ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA confuses prelink

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #8755|0                           |1
        is obsolete|                            |
   Attachment #8756|0                           |1
        is obsolete|                            |

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 8757
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8757&action=edit
A patch

Please try this one.

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

[Bug dynamic-link/19178] ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA confuses prelink

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, hjl/pr19178/master has been created
        at  1ed43952877eb3183a8093849e33c8dab0cf7ddf (commit)

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=1ed43952877eb3183a8093849e33c8dab0cf7ddf

commit 1ed43952877eb3183a8093849e33c8dab0cf7ddf
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Wed Oct 28 07:49:44 2015 -0700

    Clear ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA for prelink

    prelink runs ld.so with the environment variable LD_TRACE_PRELINKING
    set to dump the relocation type class from _dl_debug_bindings.  prelink
    has the following relocation type classes:

    where ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has a conflict with
    RTYPE_CLASS_TLS.

    Since prelink doesn't use ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, we
    should clear the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA bit when the
    DL_DEBUG_PRELINK bit is set.

        [BZ #19178]
        * elf/dl-lookup.c (RTYPE_CLASS_VALID): New.
        (RTYPE_CLASS_PLT): Likewise.
        (RTYPE_CLASS_COPY): Likewise.
        (RTYPE_CLASS_TLS): Likewise.
        (_dl_debug_bindings): Use RTYPE_CLASS_TLS and RTYPE_CLASS_VALID
        to set relocation type class for DL_DEBUG_PRELINK.  Clear the
        ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA bit for DL_DEBUG_PRELINK.

-----------------------------------------------------------------------

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

[Bug dynamic-link/19178] ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA confuses prelink

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, hjl/pr19178/master has been created
        at  7f16bc353495e6c2ec101abeee4ba26525e6c725 (commit)

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=7f16bc353495e6c2ec101abeee4ba26525e6c725

commit 7f16bc353495e6c2ec101abeee4ba26525e6c725
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Wed Oct 28 07:49:44 2015 -0700

    Keep only ELF_RTYPE_CLASS_{PLT|COPY} bits for prelink

    prelink runs ld.so with the environment variable LD_TRACE_PRELINKING
    set to dump the relocation type class from _dl_debug_bindings.  prelink
    has the following relocation type classes:

     #define RTYPE_CLASS_VALID       8
     #define RTYPE_CLASS_PLT         (8|1)
     #define RTYPE_CLASS_COPY        (8|2)
     #define RTYPE_CLASS_TLS         (8|4)

    where ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has a conflict with
    RTYPE_CLASS_TLS.

    Since prelink only uses ELF_RTYPE_CLASS_PLT and ELF_RTYPE_CLASS_COPY
    bits, we should clear the other bits when the DL_DEBUG_PRELINK bit is
    set.

        [BZ #19178]
        * elf/dl-lookup.c (RTYPE_CLASS_VALID): New.
        (RTYPE_CLASS_PLT): Likewise.
        (RTYPE_CLASS_COPY): Likewise.
        (RTYPE_CLASS_TLS): Likewise.
        (_dl_debug_bindings): Use RTYPE_CLASS_TLS and RTYPE_CLASS_VALID
        to set relocation type class for DL_DEBUG_PRELINK.  Keep only
        ELF_RTYPE_CLASS_PLT and ELF_RTYPE_CLASS_COPY bits for
        DL_DEBUG_PRELINK.

-----------------------------------------------------------------------

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

[Bug dynamic-link/19178] ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA confuses prelink

[cvs-commit at gcc dot gnu.org]

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

--- Comment #23 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Matheus Castanho
<mscastanho@sourceware.org>:

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

commit 01cdcf783a666481133d4975b1980624b0ef4799
Author: Matheus Castanho <msc@linux.ibm.com>
Date:   Tue Dec 15 15:35:41 2020 -0300

    elf: Limit tst-prelink-cmp target archs

    elf/tst-prelink-cmp was initially added for x86 (commit fe534fe898) to
validate
    the fix for Bug 19178, and later applied to all architectures that use
GLOB_DAT
    relocations (commit 89569c8bb6).  However, that bug only affected targets
that
    handle GLOB_DAT relocations as ELF_TYPE_CLASS_EXTERN_PROTECTED_DATA, so the
test
    should only apply to targets defining DL_EXTERN_PROTECTED_DATA, which gates
the
    usage of the elf type class above.  For all other targets not meeting that
    criteria, the test now returns with UNSUPPORTED status.

    Fixes the test on POWER10 processors, which started using R_PPC64_GLOB_DAT.

    Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>

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