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: Florian Weimer <fw at deneb dot enyo dot de>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org, roland at hack dot frob dot com
- Date: Sat, 18 Jul 2015 11:55:48 +0200
- 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>
* Carlos O'Donell:
> The design goal of the dynamic loader is to consume correctly formed
> ELF files and to assemble an in-memory image of the application for
> execution by the operating system and hardware.
>
> The dynamic loader will not assume the ELF files are corrupt, and
> can proceed directly to use any of the information provided and
> encoded in the format in order to carry out it's operations as
> quickly and efficiently as possible.
>
> 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.
Grudgingly, I agree.
> There are no security risks in running this way.
Correct, and I really hope it stays this way. There is considerable
interest in implementing code signing, but I have philosophical
objects to that because it can only be used to take away freedoms from
users (and device owners).