This is the mail archive of the
mailing list for the glibc project.
Re: Design goals of the dynamic loader.
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Sat, 18 Jul 2015 08:19:53 +0530
- Subject: Re: Design goals of the dynamic loader.
- Authentication-results: sourceware.org; auth=none
- References: <1437033625-13561-1-git-send-email-siddhesh at redhat dot com> <55A7D4D6 dot 9030407 at redhat dot com> <20150717032846 dot GA19592 at spoyarek dot pnq dot redhat dot com> <55A87E63 dot 5030506 at redhat dot com> <20150717043706 dot GC19592 at spoyarek dot pnq dot redhat dot com> <55A931B0 dot 1010208 at redhat dot com> <20150718014326 dot GI19592 at spoyarek dot pnq dot redhat dot com> <20150718021516 dot 002BF2C2446 at topped-with-meat dot com>
On Fri, Jul 17, 2015 at 07:15:15PM -0700, Roland McGrath wrote:
> I think we can discuss it further to understand your rationale better,
> if you care at all. Do you disagree with the notion of getting to an
> ldd that does not involve running rtld? If you intend to support the
No, I am very much in favour of getting ldd out of libc altogether; in
fact I am of the opinion that we remove those options completely from
the dynamic linker once we have a usable alternative.
> ldd case, then the motivation for graceful handling of bad ELF files
> is clear. If that is not the sole motivation, then I would like to
> hear you elaborate on what other motivations lead you to wanting this
> sort of change in rtld.
My motivation for wanting this sort of change is primarily to do with
the way the dynamic linker would behave if it weren't patched, i.e. it
would access or modify arbitrary addresses and either crash or do
something that it is not intended to do. We have a reproducer with
ldd, but the code path is not exclusive to ldd, i.e. ld.so <binary>
could trigger this as well.
We have some validations in place already, so it is not clear to me
what the criteria for selecting them is and at present it seems
arbitrary. If there is a clear guideline for what kind of sanity
checks are OK for the linker and what aren't, I can live (albeit
slightly uncomfortably since I still cannot reconcile with arbitrary
memory accesses being expected behaviour) with not adding such a