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

[Florian Weimer]

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