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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 28808 invoked from network); 23 Apr 2020 09:16:45 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 23 Apr 2020 09:16:45 -0000 Received: (qmail 9349 invoked by uid 550); 23 Apr 2020 09:16:42 -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 9331 invoked from network); 23 Apr 2020 09:16:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=zarsb+jHu+n4kcVhtMlE8Pk7eQJsUSKGgyzzrNfI9c4=; b=Q8xWeE7ZMKnKojsM8jXTc+mGtvJ08xlX/FG4b+rwuChI5uIuVCQKk9sxXMfyRivf6/ +UmiN7XUtE7yhQOk8BU5F41BAIhJKn/eelb9UAj7okUSGlybJSCQSIf84KLpot8FxNDO afqiSaX9meo8aNDf9HU0R/RyMmqQ659OyPv8lKx6T2mPnH+KDo8MP7DFp5JO4Xq9TspX udT41+cgisN54Ra0ALPw1atqYq32UIXn6l401nGoLtValBdR/agH72Y5uHhAltO+lEgi cAZL24M3q/gNP5R0KnuNj+FpyyiTwAB4Vm8V9x/gZ+MYYCV5OtCxKRITbABo0CijDKb/ TFFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=zarsb+jHu+n4kcVhtMlE8Pk7eQJsUSKGgyzzrNfI9c4=; b=mpo4EfnE93sRXIu7yeGya8RMgEShIUrTq8sAw7lrg0bp7GRShQh8KacxzKDyR8Nedo ckfZXYWSi4dJhlPZe0joCgg11cC2DHbEZGWTQFLmFhqFtWKoT2+wGiaJMbQUOMgTJFjF e8Sinrs09Exj+ysNt9WQwHpQFRMUfucCmyHFoyTlrPE28fEEpKIZMzC4/CTIkXq3/lGt ctesuKpsBBcJYQCdQRHm0HZfbbco9M11jELmA5UErSH3xK38xPYEUIYDScbtx06YkwOL fdBRxlMj1NLBQKlHnnLAVL/enshTQaAOJu9otO42UUU4JhuBoLukII92zIM6ya1Xkdpr Gglg== X-Gm-Message-State: AGi0PuZ7NY1Hu9swF7f2OOIzMYalLDmbylCS4rTh7+4qkf3+Jy26qvAv 4n+MIAZqUK3HBrcNl4i1WoPykCh+ X-Google-Smtp-Source: APiQypIjsPQe8biP7szD+7QUDho5w75MyVfaU91Z6HEhmVCSNjgmEQpPcF8lPbmr8i86jmgS1tcBPA== X-Received: by 2002:a05:6512:74:: with SMTP id i20mr1811879lfo.104.1587633390241; Thu, 23 Apr 2020 02:16:30 -0700 (PDT) Date: Thu, 23 Apr 2020 12:16:26 +0300 From: Paul Sokolovsky To: Rich Felker Cc: musl@lists.openwall.com Message-ID: <20200423121627.3e4d3ecd@zenbook> In-Reply-To: <20200423023941.GQ11469@brightrain.aerifal.cx> References: <20200423022531.502e9d26@zenbook> <20200423023941.GQ11469@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [musl] foreign-dlopen: dlopen() from static binary, again (and not the way you think!) Hello, On Wed, 22 Apr 2020 22:39:41 -0400 Rich Felker wrote: [] > > 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. [] > > 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. Thanks for the response and for the word of warning. As I mentioned, this is essentially a proof of concept, and so far was tested only by calling glibc's printf() from a host app which was either linked with glibc itself or -nostdlib and static. And that was already more than with any other ELF loader which I tried (which worked for simple functions like write(), but crashed in anything more complex like printf()). But it certainly doesn't touch a case you describe, when "foreign" vs local libc expect different values of %gs/%fs (so apparently, "foreign function call" facility would need to swap them around a call). > > 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 -- Best regards, Paul mailto:pmiscml@gmail.com