From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 6818 invoked from network); 23 Apr 2020 02:39:55 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 23 Apr 2020 02:39:55 -0000 Received: (qmail 1199 invoked by uid 550); 23 Apr 2020 02:39:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1173 invoked from network); 23 Apr 2020 02:39:53 -0000 Date: Wed, 22 Apr 2020 22:39:41 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200423023941.GQ11469@brightrain.aerifal.cx> References: <20200423022531.502e9d26@zenbook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200423022531.502e9d26@zenbook> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] foreign-dlopen: dlopen() from static binary, again (and not the way you think!) On Thu, Apr 23, 2020 at 02:25:31AM +0300, Paul Sokolovsky wrote: > Hello, > > Just as many (well, few) people I was surprised by the inability to > dlopen() from a static binary > (https://www.openwall.com/lists/musl/2012/12/08/4 , etc.). I started to > hack into musl's dynamic linker, just to find it a bit ... tangled. > That of course was nothing compared to taking a standalone ELF loader > and trying to deal with glibc's dynamic loader, that was total mess > (just look at https://github.com/robgjansen/elf-loader, which tried to > do that; tried, because it doesn't work with recent glibc versions, > and need constant patching). > > Oh, forgot to say that I'm not looking for a way to load a > particular musl-dynlinked shared library into musl-staticlinked binary. > So, arguments like "but you'll need to carry around musl's libc.so" > don't apply. What I'm looking for is a way to have a static closed-world > application, but let it, at the user's request, to interface with > whatever system may be outside. > > So, seeing what a mess is doing "honest" dynamic loading for real > world, and given my usecase, which is about wanting to touch that mess > as little as possible with bare hands, I came to a cute blackbox'ish > solution to an issue. The rest of the story and proof of concept code > is at https://github.com/pfalcon/foreign-dlopen . In your example it looks like you're foreign_dlopen'ing glibc. That simply *can't* work, because part of the interface contract of all glibc functions is that they're called with the thread pointer register (%gs or %fs on i386 or x86_64 respectively) pointing to a glibc TCB, which will not be the case when they're invoked from a musl-linked (or other non-glibc-linked) program. If you relax to the case where you're not doing that, and instead only opening *pure library* code which has no tie-in to global state or TLS contracts, then it should be able to work. Rich