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: Stan Shebs <stanshebs at google dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, roland at hack dot frob dot com
- Date: Mon, 20 Jul 2015 10:31:05 -0500
- 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>
On Fri, Jul 17, 2015 at 11:47 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>
> [...]
> The dynamic loader implementation will be as minimal as possible
> to support auditing, code coverage, unit testing, and regression
> testing. This means that any added code that is not part of the
> above purposes goes against the design goals of the dynamic loader.
>
> There are no security risks in running this way. The only security
> risk is that you ran a binary from an untrusted source, or that
> the underlying transport system was unreliable and corrupted the
> binary.
I'm just a glibc n00b, so I may be missing something, but it seems like
the stated design goal results in the code being more brittle, which leads
to security risks. Even if every code reviewer has convinced themselves
than an unchecked pointer dereference is safe, it is still possible for things
to go wrong in a way that nobody thought of - and in TLS for instance, we
are still finding and fixing holes, years after the code was written.
It used to be that we had to take these sorts of chances so as to get
reasonable performance, but I don't think that has been necessary for
awhile. Do people have statistics showing ld.so dominating execution
time?
Stan