[PATCH] Avoid mapping past end of shared object (BZ #18685)

[Mike Frysinger]

On 16 Jul 2015 22:45, Carlos O'Donell wrote:
> 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 think we need to clarify the goals before we dive into technical details.
how about:
  running `ldd <foo>` should be safe (i.e. not crash or be a security hazard)

if we can all agree on that, then a lot of things shake out from there.

> > 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.

if it's not installed, then i have no complaints :).  random/excess deps for 
debug/dev tools are fine.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20150717/f1d0a15f/attachment.sig>