From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13719 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: dlsym(handle) may search in unrelated libraries Date: Thu, 7 Feb 2019 06:33:27 +0100 Message-ID: <20190207053327.GD5469@voyager> References: <20190206160248.GB5469@voyager> <20190206202518.GC5469@voyager> <96c367533236e3e203f04a994ee65c47@ispras.ru> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="76627"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: musl@lists.openwall.com To: Alexey Izbyshev Original-X-From: musl-return-13735-gllmg-musl=m.gmane.org@lists.openwall.com Thu Feb 07 06:34:34 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1grcKX-000JoC-SX for gllmg-musl@m.gmane.org; Thu, 07 Feb 2019 06:34:33 +0100 Original-Received: (qmail 7200 invoked by uid 550); 7 Feb 2019 05:34:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7179 invoked from network); 7 Feb 2019 05:34:30 -0000 Content-Disposition: inline In-Reply-To: <96c367533236e3e203f04a994ee65c47@ispras.ru> X-Provags-ID: V03:K1:6enslE3gKtU9WZDfjdAFpXMifkiayPgfRwLOatuFypRXlWi48BP jZte4KJ/lAk0bpJgfOBS5RTHtlNIkRGAFe1JuNYGQCx5D0asxV+3wVVN9D5my7Hbl2KeQBq G+FtRTFTtJ3E3l1mtSzfJrZWhZkb5HB1S3UJtVX+KB4mYZm2G2lRUSOJ/HWpA/BFSCfSa/J hVG/0H2SCBsdCh6ZqDdcQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:dJU+CgmBkkE=:uOlIAWOJDroGpXZvTuTpFP L8FzvbUIrz+/uLsIyiyvDfGDa6JSsXMdS7n6sP+RZHiIOxi5H47cTtWARQfiYBYpAjd0spd17 twq3qh29eIuNiZexN6lmSm6KleSoCuRWaswdxe4K9b82aUXvyjUqdi+tQDOVthgxLkrGeU04y rM23W3sPR6YgpWeVXCkvfr8gbmiBwU5gPLximiXuf51EZf7LAA1GsXoi6JGidXc4ihgquooHd RQExO05L9Gvd/SU2ghALXgJe5WUbKK1w7Q73L9as+R1HwFYfZ/MtCyZCw1zYrlfeo5P2I1Jn6 aQtu000el7t/IOrAl3U+AEMLZhPIYu456aUxmYZTHN/glSEz+RIgvGDmWcQ7RarBE8B/wJblY xH0QR+iWgg2HdLbYZxKVL0I39lD2+H4kAuN8xTlkpKOH9XUwK0+qmEfqU7uhYxlpzkPpsOUj2 5eD4sGf+oDzbIiDH7ax6RVSbUb4SEMmyxY5uL7r24iPOXkuOIL2a3fYKPGwEqaW/wiXJHrh1h DFsnzx13XCmf4FHWawtDW+QlbR3xUg6Zt8UiKssmVf0UR1ZQ21SjZQZZDAkeXfWvX/fHA3Ljx nV7WiLqFZpVuxJIqtBZoNSJyNE3vdQYXSv5hS6LOUdxag2txiUk0rdcB++6ndQghq7zaEne3E PzHGhE6iz0OkBP63D9q1dtMqT1+kccJ8DTzbA3vkkGTnoRmRK3+rR05JduYfAQ5eEVcwu6Pmi VW/i3AhJj1llJ7/q8p86uNi264ZuT5SZT1qAY99Im8PQKh1IBXsSVUvNkeb186NbAgzVFLmQ Xref: news.gmane.org gmane.linux.lib.musl.general:13719 Archived-At: On Thu, Feb 07, 2019 at 12:23:06AM +0300, Alexey Izbyshev wrote: > On 2019-02-06 23:25, Markus Wichmann wrote: > > Right you are. It took me a while to understand what the deps array was > > even for (since musl's dlclose() doesn't do anything, tracking > > dependencies is mostly pointless), but I found it is needed for lazy > > relocation processing. So it is necessary for all libs opened by > > dlopen() directly to contain a list of all their dependencies. All the > > other libs can have an empty list. > > Actually, dso->deps is used in dlsym(handle) because it must use the > dependency order for symbol search, so it's incorrect to have deps empty for > "all the other" libs. Consider the following modification of my previous > example: > > $ cat bazdep.c > int bazdep = 1; > extern int bazdepdep; > int *p = &bazdepdep; > $ cat bazdepdep.c > int bazdepdep = 2; > $ cat main.c > #include > #include > > int main(void) { > if (!dlopen("libbaz.so", RTLD_NOW|RTLD_LOCAL)) > return 1; > if (!dlopen("libfoo.so", RTLD_NOW|RTLD_LOCAL)) > return 1; > void *h = dlopen("libbazdep.so", RTLD_NOW|RTLD_LOCAL); > printf("%p\n", dlsym(h, "bar")); > printf("%p\n", dlsym(h, "bazdepdep")); > } > > The correct output is zero in the first line and some non-zero address in > the second. Vanilla musl 1.1.21 prints two non-zero addresses. But with your > patch the output is two zeros because dlsym() can't search in dependencies > of "libbazdep.so" anymore. > > Alexey OK, so life just got more interesting. I gather the deps handling was always incorrect. Let's consider the original code. liba depends on libb, which depends on libc. dlopen("liba") returns a handle with libb and libc in the deps, but libb->deps == 0. If we now call dlopen("libb"), that does the right thing, but only because libb happens to be the last lib in the chain. If we'd have loaded libx, liby, and libz before trying libb, it would add all the symbols of libs x, y, and z to the libb handle. I guess the hope was that this situation never arrises. So how do we fix this? I think the easiest is probably going to be to patch up load_deps, but avoiding recursion is going to be the fun part. My plan is to make dso->deps contain all direct and indirect dependencies (which is what the code seems to depend on, anyway). This is going to consume more memory, but we are talking a few pointers, and we are dealing with shared libs, anyway. As you said, order is important. What is the correct order, depth-first or breadth-first? I think it should be depth-first, but lack any authoritative knowledge on this. It would make the most sense, anyway (if, from the point of view of a user a library contains all the symbols of its dependencies, then those dependencies must also contain all the symbols of their dependencies). So with the following dependency tree: liba->libb->libc `>libx->liby the handle for liba would list libc before libx. Easiest implementation is probably still going to be recursive. Let's hope the dependency trees don't get too wild. I'll look into it after work. Ciao, Markus