[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151016034642.GA30724@brightrain.aerifal.cx>
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.
