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

[Vivek Das Mohapatra]

> 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.