Re: Design goals of the dynamic loader.

["Carlos O'Donell" <carlos at redhat dot com>]

On 07/20/2015 11:31 AM, Stan Shebs wrote:
> 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.

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

Isn't this a self-fullfilling prophecy though? We don't show up on execution
time precisely because of the measures we take? :-)

Cheers,
Carlos.