Date: Thu, 15 Oct 2015 23:46:42 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: handling dlopen("/.../libc.so", ...) etc. 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. Rich
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.