Design goals of the dynamic loader.

[Siddhesh Poyarekar]

On Fri, Jul 17, 2015 at 07:15:15PM -0700, Roland McGrath wrote:
> I think we can discuss it further to understand your rationale better,
> if you care at all.  Do you disagree with the notion of getting to an
> ldd that does not involve running rtld?  If you intend to support the

No, I am very much in favour of getting ldd out of libc altogether; in
fact I am of the opinion that we remove those options completely from
the dynamic linker once we have a usable alternative.

> ldd case, then the motivation for graceful handling of bad ELF files
> is clear.  If that is not the sole motivation, then I would like to
> hear you elaborate on what other motivations lead you to wanting this
> sort of change in rtld.

My motivation for wanting this sort of change is primarily to do with
the way the dynamic linker would behave if it weren't patched, i.e. it
would access or modify arbitrary addresses and either crash or do
something that it is not intended to do.  We have a reproducer with
ldd, but the code path is not exclusive to ldd, i.e. ld.so <binary>
could trigger this as well.

We have some validations in place already, so it is not clear to me
what the criteria for selecting them is and at present it seems
arbitrary.  If there is a clear guideline for what kind of sanity
checks are OK for the linker and what aren't, I can live (albeit
slightly uncomfortably since I still cannot reconcile with arbitrary
memory accesses being expected behaviour) with not adding such a
check.

Siddhesh