This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Avoid mapping past end of shared object (BZ #18685)
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Andreas Schwab <schwab at linux-m68k dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org, roland at hack dot frob dot com
- Date: Thu, 16 Jul 2015 22:45:39 -0400
- Subject: Re: [PATCH] Avoid mapping past end of shared object (BZ #18685)
- 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> <87oajcjc0b dot fsf at igel dot home> <55A7E71B dot 6070808 at redhat dot com> <20150717020825 dot GG5641 at vapier>
On 07/16/2015 10:08 PM, Mike Frysinger wrote:
> On 16 Jul 2015 13:17, Carlos O'Donell wrote:
>> On 07/16/2015 12:36 PM, Andreas Schwab wrote:
>>> Perhaps ldd should use a specially compiled ld.so that has a lot of
>>> extra checks added (so that it can be run on arbitrary objects without
>>> creating security hazards).
>>
>> ldd should be a distinct tool that uses libelf, and provides deeper
>> introspection and options. This way we have a second implementation
>> of the loader rules in a cleaner and concise form that we can use
>> to double-check assertions about load order and cycle breakage,
>> and cross-check ld.so changes.
>
> i agree in having a dedicated/robust tool, but i don't think it means we should
> disable the trace option in the ldso itself. having a way to get the actual
> details out of the ldso i think is still valuable.
Agreed. We need trace to do comparison between eu-ldd and ld.so.
We need trace for developers and for runtime dumps which include
looking at dlopen/dlmopen calls. We need more trace data to look
at namespaces for dlmopen.
Making this trace robust against corrupt binaries is a questionable
endeavor though?
> i also don't think glibc should be dependent upon the elfutils package ...
It would be, but only for testing, not building, and in a bootstrap
without eu-ldd you'd just have UNSUPPORTED tests, like if you didn't
have libstdc++-static available for all the C++ tests.
c.