[RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

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

[RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Sourceware - binutils list mailing list
This patch series is in support of the glibc RTLD_SHARED work
discussed in https://sourceware.org/bugzilla/show_bug.cgi?id=22745.

It adds a DT_GNU_UNIQUE dynamic section which is intended to mark
libraries which should implicitly be opened as if RTLD_SHARED
had been passed to dlmopen when the target namespace is not
LM_ID_BASE.

This patch series adds support for DT_GNU_UNIQUE to ld, gold, and
readelf (and documents it in the help text and so forth).

Vivek Das Mohapatra (6):
  Define a new DT_GNU_UNIQUE dynamic section for ld, readelf et al
  Handle DT_GNU_UNIQUE/--unique-dso in ld
  Document --unique-dso in the man page and ld help output
  Handle DT_GNU_UNIQUE in readelf
  Define DT_GNU_UNIQUE for gold
  Implement and document DT_GNU_UNIQUE/--unique-dso handling in gold

 bfd/elflink.c        |  4 +++-
 binutils/readelf.c   | 10 ++++++++++
 elfcpp/elfcpp.h      |  2 ++
 gold/layout.cc       |  3 +++
 gold/options.h       |  4 ++++
 include/bfdlink.h    |  3 +++
 include/elf/common.h |  1 +
 ld/emultempl/elf.em  |  8 +++++++-
 ld/ld.texi           |  8 ++++++++
 ld/lexsup.c          |  2 ++
 10 files changed, 43 insertions(+), 2 deletions(-)

--
2.11.0

Reply | Threaded
Open this post in threaded view
|

[RFC][PATCH v2 1/6] Define a new DT_GNU_UNIQUE dynamic section for ld, readelf et al

Sourceware - binutils list mailing list
---
 include/elf/common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/elf/common.h b/include/elf/common.h
index 4d94c4fd5b..4d1412ed2b 100644
--- a/include/elf/common.h
+++ b/include/elf/common.h
@@ -1003,6 +1003,7 @@
    deliberate special case and we maintain it for backwards compatability.
  */
 #define DT_VALRNGLO 0x6ffffd00
+#define DT_GNU_UNIQUE   0x6ffffdf4
 #define DT_GNU_PRELINKED 0x6ffffdf5
 #define DT_GNU_CONFLICTSZ 0x6ffffdf6
 #define DT_GNU_LIBLISTSZ 0x6ffffdf7
--
2.11.0

Reply | Threaded
Open this post in threaded view
|

[RFC][PATCH v2 2/6] Handle DT_GNU_UNIQUE/--unique-dso in ld

Sourceware - binutils list mailing list
In reply to this post by Sourceware - binutils list mailing list
---
 bfd/elflink.c       | 4 +++-
 include/bfdlink.h   | 3 +++
 ld/emultempl/elf.em | 8 +++++++-
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/bfd/elflink.c b/bfd/elflink.c
index 3e56a297f6..99ecba42b3 100644
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -7124,7 +7124,9 @@ bfd_elf_size_dynamic_sections (bfd *output_bfd,
       || !_bfd_elf_add_dynamic_entry (info, DT_SYMTAB, 0)
       || !_bfd_elf_add_dynamic_entry (info, DT_STRSZ, strsize)
       || !_bfd_elf_add_dynamic_entry (info, DT_SYMENT,
-      bed->s->sizeof_sym))
+      bed->s->sizeof_sym)
+      || (info->unique_dso
+  && !_bfd_elf_add_dynamic_entry (info, DT_GNU_UNIQUE, 1)))
     return FALSE;
  }
     }
diff --git a/include/bfdlink.h b/include/bfdlink.h
index 34a0d2ec4e..d47d085d03 100644
--- a/include/bfdlink.h
+++ b/include/bfdlink.h
@@ -657,6 +657,9 @@ struct bfd_link_info
 
   /* The version information.  */
   struct bfd_elf_version_tree *version_info;
+
+  /* Tag DSO to be loaded at most once (with a DT_GNU_UNIQUE section).  */
+  unsigned int unique_dso: 1;
 };
 
 /* Some forward-definitions used by some callbacks.  */
diff --git a/ld/emultempl/elf.em b/ld/emultempl/elf.em
index c4979eb953..feecc7fbce 100644
--- a/ld/emultempl/elf.em
+++ b/ld/emultempl/elf.em
@@ -551,7 +551,8 @@ enum elf_options
   OPTION_HASH_STYLE,
   OPTION_BUILD_ID,
   OPTION_AUDIT,
-  OPTION_COMPRESS_DEBUG
+  OPTION_COMPRESS_DEBUG,
+  OPTION_UNIQUE_DSO,
 };
 
 static void
@@ -591,6 +592,7 @@ fragment <<EOF
     {"no-eh-frame-hdr", no_argument, NULL, OPTION_NO_EH_FRAME_HDR},
     {"exclude-libs", required_argument, NULL, OPTION_EXCLUDE_LIBS},
     {"hash-style", required_argument, NULL, OPTION_HASH_STYLE},
+    {"unique-dso", no_argument, NULL, OPTION_UNIQUE_DSO},
 EOF
 fi
 if test -n "$PARSE_AND_LIST_LONGOPTS" ; then
@@ -696,6 +698,10 @@ fragment <<EOF
  einfo (_("%F%P: invalid hash style \`%s'\n"), optarg);
       break;
 
+    case OPTION_UNIQUE_DSO:
+      link_info.unique_dso = 1;
+      break;
+
 EOF
 fi
 fragment <<EOF
--
2.11.0

Reply | Threaded
Open this post in threaded view
|

[RFC][PATCH v2 3/6] Document --unique-dso in the man page and ld help output

Sourceware - binutils list mailing list
In reply to this post by Sourceware - binutils list mailing list
---
 ld/ld.texi  | 8 ++++++++
 ld/lexsup.c | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/ld/ld.texi b/ld/ld.texi
index bf474d4c62..a176cfa4a1 100644
--- a/ld/ld.texi
+++ b/ld/ld.texi
@@ -1144,6 +1144,14 @@ multiple times on the command line;  It prevents the normal merging of
 input sections with the same name, overriding output section assignments
 in a linker script.
 
+@kindex --unique-dso
+@item --unique-dso
+When generating a shared library or other dynamically loadable ELF object
+mark it as one that should only ever be loaded once, and only in the main
+namespace (when using @code{dlmopen}).  This is primarily used to mark
+fundamental libraries such as libc, libpthread et al which cannot function
+correctly unless they are the sole instances of themselves.
+
 @kindex -v
 @kindex -V
 @kindex --version
diff --git a/ld/lexsup.c b/ld/lexsup.c
index d84b334b34..73a4c9fce0 100644
--- a/ld/lexsup.c
+++ b/ld/lexsup.c
@@ -1908,6 +1908,8 @@ elf_shlib_list_options (FILE *file)
   -P AUDITLIB, --depaudit=AUDITLIB\n" "\
                               Specify a library to use for auditing dependencies\n"));
   fprintf (file, _("\
+  --unique-dso                Mark DSO to be loaded at most once, and only in the main namespace\n"));
+  fprintf (file, _("\
   -z combreloc                Merge dynamic relocs into one section and sort\n"));
   fprintf (file, _("\
   -z nocombreloc              Don't merge dynamic relocs into one section\n"));
--
2.11.0

Reply | Threaded
Open this post in threaded view
|

[RFC][PATCH v2 4/6] Handle DT_GNU_UNIQUE in readelf

Sourceware - binutils list mailing list
In reply to this post by Sourceware - binutils list mailing list
---
 binutils/readelf.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/binutils/readelf.c b/binutils/readelf.c
index 101fd66ccb..1cf098d0f7 100644
--- a/binutils/readelf.c
+++ b/binutils/readelf.c
@@ -2211,6 +2211,7 @@ get_dynamic_type (Filedata * filedata, unsigned long type)
     case DT_GNU_LIBLIST: return "GNU_LIBLIST";
     case DT_GNU_LIBLISTSZ: return "GNU_LIBLISTSZ";
     case DT_GNU_HASH: return "GNU_HASH";
+    case DT_GNU_UNIQUE: return "GNU_UNIQUE";
 
     default:
       if ((type >= DT_LOPROC) && (type <= DT_HIPROC))
@@ -10914,6 +10915,15 @@ the .dynstr section doesn't match the DT_STRTAB and DT_STRSZ tags\n"));
     }
   break;
 
+ case DT_GNU_UNIQUE:
+  /* The value of this entry is currently unused.  */
+  if (do_dynamic)
+            {
+              print_vma (entry->d_un.d_val, PREFIX_HEX);
+              putchar ('\n');
+            }
+  break;
+
  default:
   if ((entry->d_tag >= DT_VERSYM) && (entry->d_tag <= DT_VERNEEDNUM))
     filedata->version_info[DT_VERSIONTAGIDX (entry->d_tag)]
--
2.11.0

Reply | Threaded
Open this post in threaded view
|

[RFC][PATCH v2 5/6] Define DT_GNU_UNIQUE for gold

Sourceware - binutils list mailing list
In reply to this post by Sourceware - binutils list mailing list
---
 elfcpp/elfcpp.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/elfcpp/elfcpp.h b/elfcpp/elfcpp.h
index 339faadaf3..2283c2a142 100644
--- a/elfcpp/elfcpp.h
+++ b/elfcpp/elfcpp.h
@@ -728,6 +728,7 @@ enum DT
 
   // The remaining values are extensions used by GNU or Solaris.
   DT_VALRNGLO = 0x6ffffd00,
+  DT_GNU_UNIQUE = 0x6ffffdf4,
   DT_GNU_PRELINKED = 0x6ffffdf5,
   DT_GNU_CONFLICTSZ = 0x6ffffdf6,
   DT_GNU_LIBLISTSZ = 0x6ffffdf7,
@@ -897,6 +898,7 @@ enum DF
 };
 
 // Flags found in the DT_FLAGS_1 dynamic element.
+// See also: include/elf/common.h
 
 enum DF_1
 {
--
2.11.0

Reply | Threaded
Open this post in threaded view
|

[RFC][PATCH v2 6/6] Implement and document DT_GNU_UNIQUE/--unique-dso handling in gold

Sourceware - binutils list mailing list
In reply to this post by Sourceware - binutils list mailing list
---
 gold/layout.cc | 3 +++
 gold/options.h | 4 ++++
 2 files changed, 7 insertions(+)

diff --git a/gold/layout.cc b/gold/layout.cc
index be437f3900..c1c727f790 100644
--- a/gold/layout.cc
+++ b/gold/layout.cc
@@ -5131,6 +5131,9 @@ Layout::add_target_dynamic_tags(bool use_rel, const Output_data* plt_got,
       // linker at run time, and used by the debugger.
       odyn->add_constant(elfcpp::DT_DEBUG, 0);
     }
+
+  if (parameters->options().unique_dso())
+    odyn->add_constant(elfcpp::DT_GNU_UNIQUE, 1);
 }
 
 void
diff --git a/gold/options.h b/gold/options.h
index b2059d984c..f1bec0cd14 100644
--- a/gold/options.h
+++ b/gold/options.h
@@ -1337,6 +1337,10 @@ class General_options
   DEFINE_set(undefined, options::TWO_DASHES, 'u',
      N_("Create undefined reference to SYMBOL"), N_("SYMBOL"));
 
+  DEFINE_bool(unique_dso, options::TWO_DASHES, '\0', false,
+              N_("Mark DSO to be loaded at most once, and only in the main namespace"),
+              NULL);
+
   DEFINE_enum(unresolved_symbols, options::TWO_DASHES, '\0', NULL,
       N_("How to handle unresolved symbols"),
       ("ignore-all,report-all,ignore-in-object-files,"
--
2.11.0

Reply | Threaded
Open this post in threaded view
|

Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Sourceware - binutils list mailing list
In reply to this post by Sourceware - binutils list mailing list
On Wed, Jun 17, 2020 at 7:08 AM Vivek Das Mohapatra via Binutils
<[hidden email]> wrote:

>
> This patch series is in support of the glibc RTLD_SHARED work
> discussed in https://sourceware.org/bugzilla/show_bug.cgi?id=22745.
>
> It adds a DT_GNU_UNIQUE dynamic section which is intended to mark
> libraries which should implicitly be opened as if RTLD_SHARED
> had been passed to dlmopen when the target namespace is not
> LM_ID_BASE.
>
> This patch series adds support for DT_GNU_UNIQUE to ld, gold, and
> readelf (and documents it in the help text and so forth).
>

Please send an email to

https://sourceware.org/mailman/listinfo/gnu-gabi

and create a merger request to document DT_GNU_UNIQUE at

https://gitlab.com/x86-psABIs/Linux-ABI

Thanks.

H.J.


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Fangrui Song-2
On 2020-06-17, H.J. Lu via Binutils wrote:

>On Wed, Jun 17, 2020 at 7:08 AM Vivek Das Mohapatra via Binutils
><[hidden email]> wrote:
>>
>> This patch series is in support of the glibc RTLD_SHARED work
>> discussed in https://sourceware.org/bugzilla/show_bug.cgi?id=22745.
>>
>> It adds a DT_GNU_UNIQUE dynamic section which is intended to mark
>> libraries which should implicitly be opened as if RTLD_SHARED
>> had been passed to dlmopen when the target namespace is not
>> LM_ID_BASE.
>>
>> This patch series adds support for DT_GNU_UNIQUE to ld, gold, and
>> readelf (and documents it in the help text and so forth).
>>

Does DT_GNU_UNIQUE perform anything not done by DF_1_NODELETE (-z nodelete)?

ld.so implementations supporting STB_GNU_UNIQUE semantics (afaik, glibc
is the only one) implicitly sets DF_1_NODELETE.

>Please send an email to
>
>https://sourceware.org/mailman/listinfo/gnu-gabi
>
>and create a merger request to document DT_GNU_UNIQUE at
>
>https://gitlab.com/x86-psABIs/Linux-ABI
>
>Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Sourceware - binutils list mailing list
> Does DT_GNU_UNIQUE perform anything not done by DF_1_NODELETE (-z nodelete)?

Yes. This is not about deletion, but about whether there should only be one
copy of a DSO resident.

In normal use, the linked list of DSOs looks like this:

   ld.so → libc.so→  libA.so→  libB.so→  …

But when namespaces are available you can have more than one:

0:  ld.so → libc.so→  libA.so→  libB.so→  …

1:  ld.so → libc.so→  lDbA.so→  EibB.so→  …

2:  …

now ld.so is special cased so there's only one of it
ever in residence: namespaces 1 and up just get a
dummy struct which actually points at the on in namespace 0:

0:  ld.so → libc.so→  libA.so→  libB.so→  …
       ↑
1:  [dummy] → libc.so→  lDbA.so→  EibB.so→  …

But it turns out that having more than 1 libc.so or
libpthread.so (and so forth) causes some problematic
behaviour - we actually want the glibc cluster of
DSOs (and maybe one or two others, possibly libgcc)
to be unique in the same way. DT_GNU_UNIQUE is the hint
to the linker/loader that this should happen.
Reply | Threaded
Open this post in threaded view
|

Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Fangrui Song-2
On 2020-06-17, Vivek Das Mohapatra wrote:

>>Does DT_GNU_UNIQUE perform anything not done by DF_1_NODELETE (-z nodelete)?
>
>Yes. This is not about deletion, but about whether there should only be one
>copy of a DSO resident.
>
>In normal use, the linked list of DSOs looks like this:
>
>  ld.so → libc.so→  libA.so→  libB.so→  …
>
>But when namespaces are available you can have more than one:
>
>0:  ld.so → libc.so→  libA.so→  libB.so→  …
>
>1:  ld.so → libc.so→  lDbA.so→  EibB.so→  …
>
>2:  …
>
>now ld.so is special cased so there's only one of it
>ever in residence: namespaces 1 and up just get a
>dummy struct which actually points at the on in namespace 0:
>
>0:  ld.so → libc.so→  libA.so→  libB.so→  …
>      ↑
>1:  [dummy] → libc.so→  lDbA.so→  EibB.so→  …
>
>But it turns out that having more than 1 libc.so or
>libpthread.so (and so forth) causes some problematic
>behaviour - we actually want the glibc cluster of
>DSOs (and maybe one or two others, possibly libgcc)
>to be unique in the same way. DT_GNU_UNIQUE is the hint
>to the linker/loader that this should happen.

Thanks. I don't claim that I understand the namespace concept so
apologize if any of the following point is irrelevant.

First, this seems like a major feature involving many components of the
toolchain.  This deserves a more detailed write-up about the problem,
considered solutions and how DT_GNU_UNIQUE is designed.

Second, by saying namespace, have you considered that C++ has one
definition rule (https://en.cppreference.com/w/cpp/language/definition )
and violating it can lead to all sorts of issues? For example, some
applications expect RTLD_LOCAL to work while others expect C++ ODR.

Prior art should be studied. Some folks consider STB_UNIQUE to be a
misfeature.

About --unique-dso, ELF specific options should use -z.
Reply | Threaded
Open this post in threaded view
|

Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Sourceware - binutils list mailing list
> First, this seems like a major feature involving many components of the
> toolchain.  This deserves a more detailed write-up about the problem,
> considered solutions and how DT_GNU_UNIQUE is designed.

It is a new feature but the complexity (and changes) reside almost
entirely within glibc, and have actually [mostly] existed for a
few years already.

DT_GNU_UNIQUE (or a new DT_FLAGS_1 value, or whatever gets chosen)
is not complicated at all - it is only a marker to indicate to
the existing linker/loader that the marked DSO should never be
duplicated (so that there's only one libc.so doing alloc/free
management, and only one libpthread managing threads).

The linker (ld or gold) only needs to add the tag or flag to the
ELF DSO - no other changes to output are required (or wanted).

> Second, by saying namespace, have you considered that C++ has one
> definition rule (https://en.cppreference.com/w/cpp/language/definition )
> and violating it can lead to all sorts of issues? For example, some
> applications expect RTLD_LOCAL to work while others expect C++ ODR.

I do not think that matters here: glibc namespaces are about runtime
linking and restricting symbol visibility between DSOs, and unless
I've misunderstood ODR is a different thing.

> About --unique-dso, ELF specific options should use -z.

The -z parameters all seemed to relate to DT_FLAGS/_1 values:
The version of this patchset that added a new DT_FLAGS_1 value
used -z unique - I wasn't sure if it was correct to use -z for
a new dynamic tag (I have no problem with doing this, I did not
want to break the apparent convention).
Reply | Threaded
Open this post in threaded view
|

Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Sourceware - binutils list mailing list
>> About --unique-dso, ELF specific options should use -z.
>
> The -z parameters all seemed to relate to DT_FLAGS/_1 values:
> The version of this patchset that added a new DT_FLAGS_1 value
> used -z unique - I wasn't sure if it was correct to use -z for
> a new dynamic tag (I have no problem with doing this, I did not
> want to break the apparent convention).

To follow up: whichever of DT_FLAGS_1/DF_1_UNIQUE or DT_GNU_UNIQUE
is used, is it acceptable for the command line parameter to be
"-z unique"?




Reply | Threaded
Open this post in threaded view
|

Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Sourceware - binutils list mailing list
On Fri, Jun 19, 2020 at 8:47 AM Vivek Das Mohapatra via Binutils
<[hidden email]> wrote:

>
> >> About --unique-dso, ELF specific options should use -z.
> >
> > The -z parameters all seemed to relate to DT_FLAGS/_1 values:
> > The version of this patchset that added a new DT_FLAGS_1 value
> > used -z unique - I wasn't sure if it was correct to use -z for
> > a new dynamic tag (I have no problem with doing this, I did not
> > want to break the apparent convention).
>
> To follow up: whichever of DT_FLAGS_1/DF_1_UNIQUE or DT_GNU_UNIQUE
> is used, is it acceptable for the command line parameter to be
> "-z unique"?

We should use "-z unique" and "-z nounique".


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Sourceware - binutils list mailing list
>> To follow up: whichever of DT_FLAGS_1/DF_1_UNIQUE or DT_GNU_UNIQUE
>> is used, is it acceptable for the command line parameter to be
>> "-z unique"?
>
> We should use "-z unique" and "-z nounique".

Thanks. Do you have a preference out of the following:

  DT_GNU_UNIQUE

  vs

  DT_FLAGS_1/DF_1_UNIQUE

Reply | Threaded
Open this post in threaded view
|

Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Sourceware - binutils list mailing list
On Fri, Jun 19, 2020 at 9:00 AM Vivek Das Mohapatra <[hidden email]> wrote:

>
> >> To follow up: whichever of DT_FLAGS_1/DF_1_UNIQUE or DT_GNU_UNIQUE
> >> is used, is it acceptable for the command line parameter to be
> >> "-z unique"?
> >
> > We should use "-z unique" and "-z nounique".
>
> Thanks. Do you have a preference out of the following:
>
>   DT_GNU_UNIQUE
>
>   vs
>
>   DT_FLAGS_1/DF_1_UNIQUE
>

DT_FLAGS_1/DF_1_UNIQUE.   Please send an email to

https://groups.google.com/forum/#!forum/generic-abi


--
H.J.
Reply | Threaded
Open this post in threaded view
|

Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Florian Weimer
In reply to this post by Sourceware - binutils list mailing list
* Vivek Das Mohapatra via Binutils:

>>> To follow up: whichever of DT_FLAGS_1/DF_1_UNIQUE or DT_GNU_UNIQUE
>>> is used, is it acceptable for the command line parameter to be
>>> "-z unique"?
>>
>> We should use "-z unique" and "-z nounique".
>
> Thanks. Do you have a preference out of the following:
>
>   DT_GNU_UNIQUE
>
>   vs
>
>   DT_FLAGS_1/DF_1_UNIQUE

We need more than a flag.  We have at least these possible states:

  * Unknown state (no indicator).

  * The object can be loaded into multiple namespaces.  (Current glibc
    behavior for everything except ld.so.)

  * The object can be loaded into one namespace.  Loads into other
    namespaces fail.

  * The object can be loaded into multiple namespaces, but subsequent
    loads re-use the previous object.  (Current glbic behavior for
    ld.so.)

And perhaps (as a future extension):

  * The object can be loaded multiple times into a single namspace.

For glibc, I think we need to keep loading libc.so into multiple
namespaces for LD_AUDIT support.  The audit modules need to be loaded
very early, triggering the loading of libc.so.  Crucially, at this
point, LD_PRELOAD is not applied.  This means that this libc.so is not
subject to malloc interposition, for example, or that libc functions
used by the audit module are not interposed by LD_PRELOAD objects.
Since audit modules affect the loading of LD_PRELOAD objects, we
cannot apply LD_PRELOAD to audit namespaces.  All this suggests to me
that the main program cannot in general use the same libc.so as an
audit module.

Maybe we need to differentiate further between dlmopen and LD_AUDIT.
In any case, a single DF_1_UNIQUE flag appears to be inadequate.
Reply | Threaded
Open this post in threaded view
|

Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Sourceware - binutils list mailing list
> We need more than a flag.  We have at least these possible states:

Not sure this is the case: More details below.

>  * Unknown state (no indicator).
>  * The object can be loaded into multiple namespaces.
>  * The object can be loaded into one namespace [only]
>  * The object can be loaded into multiple namespaces, but subsequent
>    loads re-use the previous object.  (Current glbic behavior for
>    ld.so.)

> And perhaps (as a future extension):
>  * The object can be loaded multiple times into a single namspace.

> For glibc, I think we need to keep loading libc.so into multiple
> namespaces for LD_AUDIT support.  The audit modules need to be loaded
> very early, triggering the loading of libc.so.  Crucially, at this

The patch series already behaves like this. DF_1_UNIQUE (or whatever)
doesn't enforce any behaviour. What is implementes is the following:

   * dlmopen opens an object into a selected namespace (or a new one if
     requested)

   * if RTLD_SHARED is passed, the object is opened into the base NS
     and a proxy is placed in the target NS

   * if DF_1_UNIQUE is found, the target is treated as if RTLD_SHARED
     was passed

   * BUT if RTLD_ISOLATE is passed (which the audit loading pathways do)
     then RTLD_SHARED behaviour is suppressed.

So audit libraries still result in a separate libc, as before - but
_user_ dlmopen()ed objects get to share the libc/libpthread/etc of
the base NS _by default_ which results in less surprising behaviour
(like syscalls appearing to deadlock or apparent memory corruption
when if the wrong copy of free() is called).

> cannot apply LD_PRELOAD to audit namespaces.  All this suggests to me
> that the main program cannot in general use the same libc.so as an
> audit module.

Under the current design audit modules still don't use the same libc.

> Maybe we need to differentiate further between dlmopen and LD_AUDIT.
> In any case, a single DF_1_UNIQUE flag appears to be inadequate.

I _think_ you've understood the behaviour of DF_1_UNIQUE to be more
dictatorial than it is. I have deliberately (as previously discussed)
exempted LD_AUDIT from all the new shared libc behaviour.

Apologies if I have misunderstood your objection(s).

I will of course extend the tests so far written to add checks
for continued LD_AUDIT separation and for RTLD_ISOLATE behaviour
in general before submitting a final version of the patch so
we can be sure nothing has (or will) regress.

Reply | Threaded
Open this post in threaded view
|

Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Sourceware - binutils list mailing list
* Vivek Das Mohapatra via Libc-alpha:

> The patch series already behaves like this. DF_1_UNIQUE (or whatever)
> doesn't enforce any behaviour. What is implementes is the following:
>
>   * dlmopen opens an object into a selected namespace (or a new one if
>     requested)
>
>   * if RTLD_SHARED is passed, the object is opened into the base NS
>     and a proxy is placed in the target NS
>
>   * if DF_1_UNIQUE is found, the target is treated as if RTLD_SHARED
>     was passed
>
>   * BUT if RTLD_ISOLATE is passed (which the audit loading pathways do)
>     then RTLD_SHARED behaviour is suppressed.
>
> So audit libraries still result in a separate libc, as before - but
> _user_ dlmopen()ed objects get to share the libc/libpthread/etc of
> the base NS _by default_ which results in less surprising behaviour
> (like syscalls appearing to deadlock or apparent memory corruption
> when if the wrong copy of free() is called).

So DF_1_UNIQUE in your implementation merely expresses a preference for
sharing.  That's not very unqiue. 8-/

>> cannot apply LD_PRELOAD to audit namespaces.  All this suggests to me
>> that the main program cannot in general use the same libc.so as an
>> audit module.
>
> Under the current design audit modules still don't use the same libc.
>
>> Maybe we need to differentiate further between dlmopen and LD_AUDIT.
>> In any case, a single DF_1_UNIQUE flag appears to be inadequate.
>
> I _think_ you've understood the behaviour of DF_1_UNIQUE to be more
> dictatorial than it is. I have deliberately (as previously discussed)
> exempted LD_AUDIT from all the new shared libc behaviour.

<https://gitlab.com/x86-psABIs/Linux-ABI/-/merge_requests/1/diffs?commit_id=840791b37c5680f04968c9bc7ac706391666118a>

currently has this:

| \begin{description}
|  \item[DF_GNU_1_UNIQUE]
|       If this flag is set in a shared object, only one instance of this
|       shared object should ever be loaded across the entire address
|       space.
| \end{description}

Admittedly, I based my comments on that, and not your patch.

I think the specification for DF_GNU_1_UNIQUE should be reworded.

Thanks,
Florian

Reply | Threaded
Open this post in threaded view
|

Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Sourceware - binutils list mailing list
> So DF_1_UNIQUE in your implementation merely expresses a preference for
> sharing.  That's not very unqiue. 8-/

Naming things is hard :)

I'm not wedded to the name, happy to change it - I just needed to
call it _something_ for the patch series.

> | \begin{description}
> |  \item[DF_GNU_1_UNIQUE]
> |       If this flag is set in a shared object, only one instance of this
> |       shared object should ever be loaded across the entire address
> |       space.
> | \end{description}
>
> Admittedly, I based my comments on that, and not your patch.
>
> I think the specification for DF_GNU_1_UNIQUE should be reworded.

Fair enough. I'll propose updated wording:

I need to update the patches anyway since I think the flag had
been pushed into a new dynamic tag as solaris already exhausted
the 32 bits in use in DT_FLAGS_1.


12