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

Florian Weimer fweimer@redhat.com
Mon Jun 29 10:21:42 GMT 2020

* 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
|       space.
| \end{description}