[RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE
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
> * 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.
currently has this:
| If this flag is set in a shared object, only one instance of this
| shared object should ever be loaded across the entire address
Admittedly, I based my comments on that, and not your patch.
I think the specification for DF_GNU_1_UNIQUE should be reworded.
More information about the Libc-alpha