Date: Fri, 16 Oct 2015 11:31:31 +0700 From: Рысь <lynx@...xlynx.tk> To: musl@...ts.openwall.com Subject: Re: handling dlopen("/.../libc.so", ...) etc. On Fri, 16 Oct 2015 00:18:32 -0400 Rich Felker <dalias@...c.org> wrote: > On Fri, Oct 16, 2015 at 11:00:11AM +0700, Рысь wrote: > > On Thu, 15 Oct 2015 23:46:42 -0400 > > Rich Felker <dalias@...c.org> 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 > OK. You have a good ELF interpreter inside - just add object file "tag" and match it when you're reading ELF structures from file. -- http://lynxlynx.tk/ Power electronics made simple Unix and simple KISS C code
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.