From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84561 invoked by alias); 24 Jan 2018 17:25:36 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 82777 invoked by uid 89); 24 Jan 2018 17:25:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=set*, exam, states X-HELO: mail-qt0-f173.google.com Received: from mail-qt0-f173.google.com (HELO mail-qt0-f173.google.com) (209.85.216.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Jan 2018 17:25:33 +0000 Received: by mail-qt0-f173.google.com with SMTP id z11so12283870qtm.3 for ; Wed, 24 Jan 2018 09:25:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uGPPHvbBRnzojCd3L1I1RRGUAEd8099Di7pHVsPBq2Y=; b=XS2qkLYCLuxRm9Uc1S1+wMaQv/C7u2WUvLVSNQgKv6FP0ePtzbbdGHlIjIiKjjPrbw iXDgFXpc4GDWC+Inx5FSdyf8kQFi7gFFTKSAVSCJtBq1ovywtoWAcTh5Q/N/IitrwExq m5+Mpi14JTrP1qs3m4wPMwWeW8IDQfaDQXjvAjvG3PRlZxYXOrb3XHWJZR6r6itycuiH BrM4yqdWdgDh3G62EzDNTfmpPdjnaAoqb4EQLNIlWQTJJFJwER4egtFawPjqPMrtz1dg cNvg6KS+xerwCWr/EmQPEnp/yuTamhb9z8WHulATYS9q9DQ8JtPb6Tk26mwCP2s4Q6ge pf2Q== X-Gm-Message-State: AKwxytdr4MkpUVnsupfY9ydt/zvvaqB3EOl2P2qd8P2QmnKFZ7R6PoE6 EkZAtU2Q/bpOoxFv3627M93o/dfeFi8= X-Google-Smtp-Source: AH8x226ihh8MwA2Gbr5PbTIjNQ6u1txdcJyalKeSrQZMGQlYtFtAZeeJFu5fdtZ+O3EBzTNm3s6RqQ== X-Received: by 10.237.37.18 with SMTP id v18mr10658038qtc.124.1516814731346; Wed, 24 Jan 2018 09:25:31 -0800 (PST) Received: from [10.0.0.2] ([179.159.9.95]) by smtp.googlemail.com with ESMTPSA id y123sm554171qka.42.2018.01.24.09.25.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 09:25:30 -0800 (PST) Subject: Re: A possible libc/dlmopen/pthreads bug To: libc-help@sourceware.org References: <41b64265-397f-1ead-dd79-50052b2d19af@arm.com> From: Adhemerval Zanella Message-ID: <9ff5882f-879f-3069-1ea0-268e2c5e6ac0@linaro.org> Date: Wed, 24 Jan 2018 17:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <41b64265-397f-1ead-dd79-50052b2d19af@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00013.txt.bz2 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/