diff mbox series

[v2] elf: Remove ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA

Message ID 20220601045033.809671-1-maskray@google.com
State New
Headers show
Series [v2] elf: Remove ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA | expand

Commit Message

Fangrui Song June 1, 2022, 4:50 a.m. UTC 
If an executable has copy relocations for extern protected data, that
can only work if the library containing the definition is built with
assumptions (a) the compiler emits GOT-generating relocations (b) the
linker produces R_*_GLOB_DAT instead of R_*_RELATIVE.  Otherwise the
library uses its own definition directly and the executable accesses a
stale copy.  Note: the GOT relocations defeat the purpose of protected
visibility as an optimization, but allow rtld to make the executable and
library use the same copy when copy relocations are present, but it
turns out this never worked perfectly.

ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has strange semantics when both
a.so and b.so define protected var and the executable copy relocates
var: b.so accesses its own copy even with GLOB_DAT.  The behavior change
is from commit 62da1e3b00b51383ffa7efc89d8addda0502e107 (x86) and then
copied to nios2 (ae5eae7cfc9c4a8297ff82ec6b794faca1976ecc) and arc
(0e7d930c4c11de896fe807f67fa1eb756c9c1e05).

Without ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, b.so accesses the copy
relocated data like a.so.

It's extremely unlikely anyone relies on the
ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA behavior, so let's remove it.

--
Changes from v1:
* Reword commit message as suggested by Szabolcs Nagy
---
 elf/dl-lookup.c             | 90 -------------------------------------
 sysdeps/arc/dl-sysdep.h     | 21 ---------
 sysdeps/generic/ldsodefs.h  | 12 +----
 sysdeps/i386/dl-machine.h   |  3 +-
 sysdeps/nios2/dl-sysdep.h   | 21 ---------
 sysdeps/x86/dl-lookupcfg.h  |  4 --
 sysdeps/x86_64/dl-machine.h |  8 +---
 7 files changed, 4 insertions(+), 155 deletions(-)
 delete mode 100644 sysdeps/arc/dl-sysdep.h
 delete mode 100644 sysdeps/nios2/dl-sysdep.h

Comments

Szabolcs Nagy June 1, 2022, 7:26 a.m. UTC | #1 
The 05/31/2022 21:50, Fangrui Song wrote:
> If an executable has copy relocations for extern protected data, that
> can only work if the library containing the definition is built with
> assumptions (a) the compiler emits GOT-generating relocations (b) the
> linker produces R_*_GLOB_DAT instead of R_*_RELATIVE.  Otherwise the
> library uses its own definition directly and the executable accesses a
> stale copy.  Note: the GOT relocations defeat the purpose of protected
> visibility as an optimization, but allow rtld to make the executable and
> library use the same copy when copy relocations are present, but it
> turns out this never worked perfectly.
> 
> ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has strange semantics when both
> a.so and b.so define protected var and the executable copy relocates
> var: b.so accesses its own copy even with GLOB_DAT.  The behavior change
> is from commit 62da1e3b00b51383ffa7efc89d8addda0502e107 (x86) and then
> copied to nios2 (ae5eae7cfc9c4a8297ff82ec6b794faca1976ecc) and arc
> (0e7d930c4c11de896fe807f67fa1eb756c9c1e05).
> 
> Without ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, b.so accesses the copy
> relocated data like a.so.
> 
> It's extremely unlikely anyone relies on the
> ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA behavior, so let's remove it.
> 
> --
> Changes from v1:
> * Reword commit message as suggested by Szabolcs Nagy

Please document the interposition change or fix it.

That is important as it affects binaries without copy relocation.
Fangrui Song June 1, 2022, 7:34 a.m. UTC | #2 
On 2022-06-01, Szabolcs Nagy wrote:
>The 05/31/2022 21:50, Fangrui Song wrote:
>> If an executable has copy relocations for extern protected data, that
>> can only work if the library containing the definition is built with
>> assumptions (a) the compiler emits GOT-generating relocations (b) the
>> linker produces R_*_GLOB_DAT instead of R_*_RELATIVE.  Otherwise the
>> library uses its own definition directly and the executable accesses a
>> stale copy.  Note: the GOT relocations defeat the purpose of protected
>> visibility as an optimization, but allow rtld to make the executable and
>> library use the same copy when copy relocations are present, but it
>> turns out this never worked perfectly.
>>
>> ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has strange semantics when both
>> a.so and b.so define protected var and the executable copy relocates
>> var: b.so accesses its own copy even with GLOB_DAT.  The behavior change
>> is from commit 62da1e3b00b51383ffa7efc89d8addda0502e107 (x86) and then
>> copied to nios2 (ae5eae7cfc9c4a8297ff82ec6b794faca1976ecc) and arc
>> (0e7d930c4c11de896fe807f67fa1eb756c9c1e05).
>>
>> Without ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, b.so accesses the copy
>> relocated data like a.so.
>>
>> It's extremely unlikely anyone relies on the
>> ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA behavior, so let's remove it.
>>
>> --
>> Changes from v1:
>> * Reword commit message as suggested by Szabolcs Nagy
>
>Please document the interposition change or fix it.

Does this paragraph count as an explanation?
"Without ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, b.so accesses the copy relocated data like a.so."

Or, what other documentation on the interposition behavior do you expect?

>That is important as it affects binaries without copy relocation.
Szabolcs Nagy June 1, 2022, 9:53 a.m. UTC | #3 
The 06/01/2022 00:34, Fangrui Song wrote:
> On 2022-06-01, Szabolcs Nagy wrote:
> > The 05/31/2022 21:50, Fangrui Song wrote:
> > > If an executable has copy relocations for extern protected data, that
> > > can only work if the library containing the definition is built with
> > > assumptions (a) the compiler emits GOT-generating relocations (b) the
> > > linker produces R_*_GLOB_DAT instead of R_*_RELATIVE.  Otherwise the
> > > library uses its own definition directly and the executable accesses a
> > > stale copy.  Note: the GOT relocations defeat the purpose of protected
> > > visibility as an optimization, but allow rtld to make the executable and
> > > library use the same copy when copy relocations are present, but it
> > > turns out this never worked perfectly.
> > > 
> > > ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has strange semantics when both
> > > a.so and b.so define protected var and the executable copy relocates
> > > var: b.so accesses its own copy even with GLOB_DAT.  The behavior change
> > > is from commit 62da1e3b00b51383ffa7efc89d8addda0502e107 (x86) and then
> > > copied to nios2 (ae5eae7cfc9c4a8297ff82ec6b794faca1976ecc) and arc
> > > (0e7d930c4c11de896fe807f67fa1eb756c9c1e05).
> > > 
> > > Without ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, b.so accesses the copy
> > > relocated data like a.so.
> > > 
> > > It's extremely unlikely anyone relies on the
> > > ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA behavior, so let's remove it.
> > > 
> > > --
> > > Changes from v1:
> > > * Reword commit message as suggested by Szabolcs Nagy
> > 
> > Please document the interposition change or fix it.
> 
> Does this paragraph count as an explanation?
> "Without ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, b.so accesses the copy relocated data like a.so."
> 
> Or, what other documentation on the interposition behavior do you expect?

the current commit message implies there is only behaviour
change in presence of copy relocations.

but that's not true: the exe (or a shared lib) can now
interpose a protected variable by another one with the
same name (and no copy relocs).

i originally thought that warning/rejecting copy relocs in
ld is enough to get sane behaviour for protected symbols,
but when multiple definitions are present the behaviour
will depend on ld's decision to use GOT or not.

i think the removed logic tried to ensure that GOT relocs
resolve to the definition within the same shared lib for
protected data. (i.e. ld's decision does not matter.)

if we want to allow ld to not use GOT then i think we need
to keep the logic that makes GOT behave consistently with
that future.

if we instead want to simplify ld.so and handle GOT for
protected symbols more efficiently, then that should be
explained in the commit clearly: why do we choose the
"symbol lookup returns a unique address" over "protected
symbol binds locally" rule when there are multiple
definitions? (maybe because this case should not be
relied on but then we should diagnose it, etc)
Florian Weimer June 1, 2022, 10:56 a.m. UTC | #4 
* Szabolcs Nagy via Libc-alpha:

> but that's not true: the exe (or a shared lib) can now
> interpose a protected variable by another one with the
> same name (and no copy relocs).

That's not desirable at all, I think.  It's certainly very surprising.

> i originally thought that warning/rejecting copy relocs in
> ld is enough to get sane behaviour for protected symbols,
> but when multiple definitions are present the behaviour
> will depend on ld's decision to use GOT or not.
>
> i think the removed logic tried to ensure that GOT relocs
> resolve to the definition within the same shared lib for
> protected data. (i.e. ld's decision does not matter.)
>
> if we want to allow ld to not use GOT then i think we need
> to keep the logic that makes GOT behave consistently with
> that future.

I agree.  I have this mental model that protected symbols behave like
-Bsymbolic.  The ELF specification also seems to require that the symbol
cannot be preempted.

Thanks,
Florian
Fangrui Song June 2, 2022, 5:21 a.m. UTC | #5 
On 2022-06-01, Florian Weimer wrote:
>* Szabolcs Nagy via Libc-alpha:
>
>> but that's not true: the exe (or a shared lib) can now
>> interpose a protected variable by another one with the
>> same name (and no copy relocs).
>
>That's not desirable at all, I think.  It's certainly very surprising.
>
>> i originally thought that warning/rejecting copy relocs in
>> ld is enough to get sane behaviour for protected symbols,
>> but when multiple definitions are present the behaviour
>> will depend on ld's decision to use GOT or not.
>>
>> i think the removed logic tried to ensure that GOT relocs
>> resolve to the definition within the same shared lib for
>> protected data. (i.e. ld's decision does not matter.)
>>
>> if we want to allow ld to not use GOT then i think we need
>> to keep the logic that makes GOT behave consistently with
>> that future.
>
>I agree.  I have this mental model that protected symbols behave like
>-Bsymbolic.  The ELF specification also seems to require that the symbol
>cannot be preempted.

Yes.  I just send two GNU ld patches (arm and aarch64) to restore the
previous behavior whether ld -shared produces RELATIVE instead of
GLOB_DAT for GOT-generating relocations referencing a protected data
symbol:
https://sourceware.org/pipermail/binutils/2022-June/
diff mbox series

Patch

diff --git a/elf/dl-lookup.c b/elf/dl-lookup.c
index a42f6d5390..41d108e0b8 100644
--- a/elf/dl-lookup.c
+++ b/elf/dl-lookup.c
@@ -456,59 +456,6 @@  do_lookup_x (const char *undef_name, unsigned int new_hash,
       if (sym != NULL)
 	{
 	found_it:
-	  /* When UNDEF_MAP is NULL, which indicates we are called from
-	     do_lookup_x on relocation against protected data, we skip
-	     the data definion in the executable from copy reloc.  */
-	  if (ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA
-	      && undef_map == NULL
-	      && map->l_type == lt_executable
-	      && type_class == ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA)
-	    {
-	      const ElfW(Sym) *s;
-	      unsigned int i;
-
-#if ! ELF_MACHINE_NO_RELA
-	      if (map->l_info[DT_RELA] != NULL
-		  && map->l_info[DT_RELASZ] != NULL
-		  && map->l_info[DT_RELASZ]->d_un.d_val != 0)
-		{
-		  const ElfW(Rela) *rela
-		    = (const ElfW(Rela) *) D_PTR (map, l_info[DT_RELA]);
-		  unsigned int rela_count
-		    = map->l_info[DT_RELASZ]->d_un.d_val / sizeof (*rela);
-
-		  for (i = 0; i < rela_count; i++, rela++)
-		    if (elf_machine_type_class (ELFW(R_TYPE) (rela->r_info))
-			== ELF_RTYPE_CLASS_COPY)
-		      {
-			s = &symtab[ELFW(R_SYM) (rela->r_info)];
-			if (!strcmp (strtab + s->st_name, undef_name))
-			  goto skip;
-		      }
-		}
-#endif
-#if ! ELF_MACHINE_NO_REL
-	      if (map->l_info[DT_REL] != NULL
-		  && map->l_info[DT_RELSZ] != NULL
-		  && map->l_info[DT_RELSZ]->d_un.d_val != 0)
-		{
-		  const ElfW(Rel) *rel
-		    = (const ElfW(Rel) *) D_PTR (map, l_info[DT_REL]);
-		  unsigned int rel_count
-		    = map->l_info[DT_RELSZ]->d_un.d_val / sizeof (*rel);
-
-		  for (i = 0; i < rel_count; i++, rel++)
-		    if (elf_machine_type_class (ELFW(R_TYPE) (rel->r_info))
-			== ELF_RTYPE_CLASS_COPY)
-		      {
-			s = &symtab[ELFW(R_SYM) (rel->r_info)];
-			if (!strcmp (strtab + s->st_name, undef_name))
-			  goto skip;
-		      }
-		}
-#endif
-	    }
-
 	  /* Hidden and internal symbols are local, ignore them.  */
 	  if (__glibc_unlikely (dl_symbol_visibility_binds_local_p (sym)))
 	    goto skip;
@@ -854,43 +801,6 @@  _dl_lookup_symbol_x (const char *undef_name, struct link_map *undef_map,
       return 0;
     }
 
-  int protected = (*ref
-		   && ELFW(ST_VISIBILITY) ((*ref)->st_other) == STV_PROTECTED);
-  if (__glibc_unlikely (protected != 0))
-    {
-      /* It is very tricky.  We need to figure out what value to
-	 return for the protected symbol.  */
-      if (type_class == ELF_RTYPE_CLASS_PLT)
-	{
-	  if (current_value.s != NULL && current_value.m != undef_map)
-	    {
-	      current_value.s = *ref;
-	      current_value.m = undef_map;
-	    }
-	}
-      else
-	{
-	  struct sym_val protected_value = { NULL, NULL };
-
-	  for (scope = symbol_scope; *scope != NULL; i = 0, ++scope)
-	    if (do_lookup_x (undef_name, new_hash, &old_hash, *ref,
-			     &protected_value, *scope, i, version, flags,
-			     skip_map,
-			     (ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA
-			      && ELFW(ST_TYPE) ((*ref)->st_info) == STT_OBJECT
-			      && type_class == ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA)
-			     ? ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA
-			     : ELF_RTYPE_CLASS_PLT, NULL) != 0)
-	      break;
-
-	  if (protected_value.s != NULL && protected_value.m != undef_map)
-	    {
-	      current_value.s = *ref;
-	      current_value.m = undef_map;
-	    }
-	}
-    }
-
   /* We have to check whether this would bind UNDEF_MAP to an object
      in the global scope which was dynamically loaded.  In this case
      we have to prevent the latter from being unloaded unless the
diff --git a/sysdeps/arc/dl-sysdep.h b/sysdeps/arc/dl-sysdep.h
deleted file mode 100644
index cf4d160a73..0000000000
--- a/sysdeps/arc/dl-sysdep.h
+++ /dev/null
@@ -1,21 +0,0 @@ 
-/* System-specific settings for dynamic linker code.  ARC version.
-   Copyright (C) 2020-2022 Free Software Foundation, Inc.
-   This file is part of the GNU C Library.
-
-   The GNU C Library is free software; you can redistribute it and/or
-   modify it under the terms of the GNU Lesser General Public
-   License as published by the Free Software Foundation; either
-   version 2.1 of the License, or (at your option) any later version.
-
-   The GNU C Library is distributed in the hope that it will be useful,
-   but WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-   Lesser General Public License for more details.
-
-   You should have received a copy of the GNU Lesser General Public
-   License along with the GNU C Library.  If not, see
-   <https://www.gnu.org/licenses/>.  */
-
-#include_next <dl-sysdep.h>
-
-#define DL_EXTERN_PROTECTED_DATA
diff --git a/sysdeps/generic/ldsodefs.h b/sysdeps/generic/ldsodefs.h
index 6716e1f382..d3cbfd4f95 100644
--- a/sysdeps/generic/ldsodefs.h
+++ b/sysdeps/generic/ldsodefs.h
@@ -149,23 +149,13 @@  dl_symbol_visibility_binds_local_p (const ElfW(Sym) *sym)
    satisfied by any symbol in the executable.  Some architectures do
    not support copy relocations.  In this case we define the macro to
    zero so that the code for handling them gets automatically optimized
-   out.  ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA means address of protected
-   data defined in the shared library may be external, i.e., due to copy
-   relocation.  */
+   out.  */
 #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
 
 /* ELF uses the PF_x macros to specify the segment permissions, mmap
    uses PROT_xxx.  In most cases the three macros have the values 1, 2,
diff --git a/sysdeps/i386/dl-machine.h b/sysdeps/i386/dl-machine.h
index 1f8d734215..3311631a3e 100644
--- a/sysdeps/i386/dl-machine.h
+++ b/sysdeps/i386/dl-machine.h
@@ -203,8 +203,7 @@  _dl_start_user:\n\
      || (type) == R_386_TLS_DTPOFF32 || (type) == R_386_TLS_TPOFF32	      \
      || (type) == R_386_TLS_TPOFF || (type) == R_386_TLS_DESC)		      \
     * ELF_RTYPE_CLASS_PLT)						      \
-   | (((type) == R_386_COPY) * ELF_RTYPE_CLASS_COPY)			      \
-   | (((type) == R_386_GLOB_DAT) * ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA))
+   | (((type) == R_386_COPY) * ELF_RTYPE_CLASS_COPY))
 
 /* A reloc type used for ld.so cmdline arg lookups to reject PLT entries.  */
 #define ELF_MACHINE_JMP_SLOT	R_386_JMP_SLOT
diff --git a/sysdeps/nios2/dl-sysdep.h b/sysdeps/nios2/dl-sysdep.h
deleted file mode 100644
index 257b37c258..0000000000
--- a/sysdeps/nios2/dl-sysdep.h
+++ /dev/null
@@ -1,21 +0,0 @@ 
-/* System-specific settings for dynamic linker code.  Nios II version.
-   Copyright (C) 2009-2022 Free Software Foundation, Inc.
-   This file is part of the GNU C Library.
-
-   The GNU C Library is free software; you can redistribute it and/or
-   modify it under the terms of the GNU Lesser General Public
-   License as published by the Free Software Foundation; either
-   version 2.1 of the License, or (at your option) any later version.
-
-   The GNU C Library is distributed in the hope that it will be useful,
-   but WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-   Lesser General Public License for more details.
-
-   You should have received a copy of the GNU Lesser General Public
-   License along with the GNU C Library.  If not, see
-   <https://www.gnu.org/licenses/>.  */
-
-#include_next <dl-sysdep.h>
-
-#define DL_EXTERN_PROTECTED_DATA
diff --git a/sysdeps/x86/dl-lookupcfg.h b/sysdeps/x86/dl-lookupcfg.h
index 18b3b49f6e..e136cc63af 100644
--- a/sysdeps/x86/dl-lookupcfg.h
+++ b/sysdeps/x86/dl-lookupcfg.h
@@ -20,10 +20,6 @@ 
 
 #include_next <dl-lookupcfg.h>
 
-/* Address of protected data defined in the shared library may be
-   external due to copy relocation.   */
-#define DL_EXTERN_PROTECTED_DATA
-
 struct link_map;
 
 extern void _dl_unmap (struct link_map *map) attribute_hidden;
diff --git a/sysdeps/x86_64/dl-machine.h b/sysdeps/x86_64/dl-machine.h
index 7f607f6dff..78aecfc9fd 100644
--- a/sysdeps/x86_64/dl-machine.h
+++ b/sysdeps/x86_64/dl-machine.h
@@ -181,10 +181,7 @@  _dl_start_user:\n\
    TLS variable, so undefined references should not be allowed to
    define the value.
    ELF_RTYPE_CLASS_COPY iff TYPE should not be allowed to resolve to one
-   of the main executable's symbols, as for a COPY reloc.
-   ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA iff TYPE describes relocation may
-   against protected data whose address be external due to copy relocation.
- */
+   of the main executable's symbols, as for a COPY reloc.  */
 #define elf_machine_type_class(type)					      \
   ((((type) == R_X86_64_JUMP_SLOT					      \
      || (type) == R_X86_64_DTPMOD64					      \
@@ -192,8 +189,7 @@  _dl_start_user:\n\
      || (type) == R_X86_64_TPOFF64					      \
      || (type) == R_X86_64_TLSDESC)					      \
     * ELF_RTYPE_CLASS_PLT)						      \
-   | (((type) == R_X86_64_COPY) * ELF_RTYPE_CLASS_COPY)			      \
-   | (((type) == R_X86_64_GLOB_DAT) * ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA))
+   | (((type) == R_X86_64_COPY) * ELF_RTYPE_CLASS_COPY))
 
 /* A reloc type used for ld.so cmdline arg lookups to reject PLT entries.  */
 #define ELF_MACHINE_JMP_SLOT	R_X86_64_JUMP_SLOT