handling dlopen("/.../libc.so", ...) etc.

handling dlopen("/.../libc.so", ...) etc.

[Rich Felker]

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

Re: handling dlopen("/.../libc.so", ...) etc.

[Рысь]

On Thu, 15 Oct 2015 23:46:42 -0400
Rich Felker <dalias@libc.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.
> 
> Rich

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.

-- 
http://lynxlynx.tk/
Power electronics made simple
Unix and simple KISS C code

Re: handling dlopen("/.../libc.so", ...) etc.

[Rich Felker]

On Fri, Oct 16, 2015 at 11:00:11AM +0700, Рысь wrote:
> On Thu, 15 Oct 2015 23:46:42 -0400
> Rich Felker <dalias@libc.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

Re: handling dlopen("/.../libc.so", ...) etc.

[Рысь]

On Fri, 16 Oct 2015 00:18:32 -0400
Rich Felker <dalias@libc.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@libc.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