This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Design goals of the dynamic loader.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 20 Jul 2015 08:56:08 -0400
- 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> <20150718024952 dot GJ19592 at spoyarek dot pnq dot redhat dot com>
On 07/17/2015 10:49 PM, Siddhesh Poyarekar wrote:
> 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.
I agree completely, but we would need to replace it with something like
stap-based probe tracing which compiles to nop's normally but allows an
external program like systemtrace to be used to trace library loading with
all the same detailed data as before but for developers only (and ship
the stap script with libc.so.6).
>> 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
> check.
It important to have these discussions. We should have community
members with different view points, and be ready to use those views
to better serve our users should the needs of those users change.
I too find a certain degree of cognitive dissonance between what I
as a developer want in ld.so and what our users want. I want a robust
ld.so, but our users want performance. Therefore I judge the best
criteria to be two distinct tools e.g. ld.so and ldd (which has all
or most of the trace features of ld.so).
Cheers,
Carlos.