This is the mail archive of the
mailing list for the glibc project.
Re: Design goals of the dynamic loader.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Stan Shebs <stanshebs at google 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 11:39:48 -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> <CA+5-Q5+z2t9KUc4+-fQwgKXn87wH-oBY4NghvXV568zeky5yTg at mail dot gmail dot com>
On 07/20/2015 11:31 AM, Stan Shebs wrote:
> On Fri, Jul 17, 2015 at 11:47 AM, Carlos O'Donell <email@example.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
> 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.
The design goal sets the bar high, and forces you to argue for your change
with solid evidence and fact. It's just a goal after all and we often fall
> 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
Isn't this a self-fullfilling prophecy though? We don't show up on execution
time precisely because of the measures we take? :-)