From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8686 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: handling dlopen("/.../libc.so", ...) etc. Date: Fri, 16 Oct 2015 00:18:32 -0400 Message-ID: <20151016041832.GG8645@brightrain.aerifal.cx> References: <20151016034642.GA30724@brightrain.aerifal.cx> <20151016110011.39f7b444@r2lynx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1444969130 19621 80.91.229.3 (16 Oct 2015 04:18:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Oct 2015 04:18:50 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8698-gllmg-musl=m.gmane.org@lists.openwall.com Fri Oct 16 06:18:49 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZmwTg-0002j2-So for gllmg-musl@m.gmane.org; Fri, 16 Oct 2015 06:18:48 +0200 Original-Received: (qmail 17692 invoked by uid 550); 16 Oct 2015 04:18:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17674 invoked from network); 16 Oct 2015 04:18:44 -0000 Content-Disposition: inline In-Reply-To: <20151016110011.39f7b444@r2lynx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8686 Archived-At: On Fri, Oct 16, 2015 at 11:00:11AM +0700, Рысь wrote: > On Thu, 15 Oct 2015 23:46:42 -0400 > Rich Felker wrote: > > > Presently, attempting to load "libc.so" (without pathname) or a number > > of other standard library names via dlopen suppresses the actual > > loading and returns a reference to the existing libc dso object. > > However, loading it via a pathname or alternate name/symlink will > > actually cause another copy to be loaded into memory (since we can't > > check the dev/ino against the existing one, because the kernel didn't > > give those to us) and bad things will happen. I've been thinking some > > about ways to prevent that. > > > > The most obvious way is to link libc.so with -Wl,-z,nodlopen and make > > the dynamic linker enforce DF_1_NOOPEN, but this would cause the load > > to fail when we probably want it to succeed but return a reference to > > the existing libc. > > > > Another option would be to somehow encode musl's identity in libc.so > > so that the loader code can check "is the dso we've just loaded > > actually musl?" In that case it can abort the load and use the > > existing libc instead. Options for how to do this might include a > > special reserved-namespace symbol. If an approach like this is taken, > > it would be ideal to be able to detect existing/previous versions of > > libc.so (to avoid loading them too), and the approach should be > > future-proof so that the current libc.so can avoid loading future > > versions of itself, and so that future versions can avoid loading the > > current version. > > > > I'd like to hear any further ideas on how to achieve this. > > Who would even want to load "libc.so"? I mean, does not it already > being loaded in every libc implementations with dynamic linking support > already today? > > And what are use cases? Who does this today? I am confused. It could be a program calling dlopen on the pathname of each library it knows is loaded (e.g. obtained from dl_iterate_phdr or /proc/self/maps) to obtain handles for them -- the intent then is _not_ to load anything new, but to get module handles for stuff that's already loaded. In that case RTLD_NOLOAD should be used, but it might not be, and even if it is used you want success rather than failure. Similar situations could arise from programmatically reading DT_NEEDED records to manually load dependencies before loading a library, e.g. to try to control order ctors run or something. In any case, the main concern is to _prevent_ wrongful loading of multiple copies of libc.so that could read to serious issues like memory corruption. The -Wl,-z,nodlopen approach solves this, but it would be nicer if attempting to open a full pathname to libc.so behaved just like opening the string "libc.so". Does that answer your questions? Rich