Re: A possible libc/dlmopen/pthreads bug

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 24/01/2018 14:52, Szabolcs Nagy wrote:
> On 24/01/18 13:59, Vivek Das Mohapatra wrote:
>> Apologies for the exegesis: It seems to me that the copy of libc in the
>> private namespace has somehow managed to scribble on the linked list
>> pointed to by __stack_user, overwriting a key address.
>>
>> Is my analysis correct? Is there something I could or should have done to
>> avoid this?
>>
>> A while ago (https://sourceware.org/ml/libc-help/2018-01/msg00002.html)
>> I suggested a dlmopen flag RTLD_UNIQUE or similar which would cause the
>> existing mapping of the target library in the main namespace/link-map to be
>> re-used instead of creating a new one: I believe this would prevent this
>> problem (and others detailed in that message) from occurring - any thoughts?
> 
> i don't know what you are doing, but it's hard to imagine
> that two libcs (or libpthreads) would work in the same
> process: if they can run code on the same thread they
> cannot both control the tcb (and will clobber each other's
> global state through that).
> 
> same for signal handlers (for internal signals) or
> brk syscall, or stdio buffering, etc. the libc has to
> deal with process global/thread local state that must
> be controlled by the same code consistently otherwise
> bad things happen.

Unfortunately glibc manual lacks the description and semantic of dlfcn
functions and man-pages does not cover the global resources shared.
Considering the API is derived from SunOS and also that OpenSolaris
manual [1] states that:

"When an object is loaded on a new link-map list, the object is isolated from the main run-
 ning program. Certain global resources are only usable from one link-map list. A few exam-
 ples  are  the  sbrk()  based  malloc(), libthread(), and the signal vectors. Care must be
 taken not to use any of these resources other than from the primary link-map  list.  These
 issues are discussed in further detail in the Linker and Libraries Guide."

I think we should first discuss which is the expected semantic of dlmopen
regarding shared resources.  Although OpenSolaris manual is a bit vague
about it, I still think complete isolation as Viver is expecting is quite
hard as far from current code expectations.

In fact I think Vivek examples of running process with two different libcs 
are working mainly because the different glibc define and access the shared 
resources in same manner.  I bet it will break the moment we change some 
state internal layout or semantic (for instance the __stack_user struct size).

Also, I think some API will mainly just not work as expect, for instance
posix timers, posix thread cancellation, or set* functions.

[1] https://www.unix.com/man-page/opensolaris/3C/dlmopen/