Design goals of the dynamic loader.

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

> We don't know the cost of verification yet.  We fear that it will be
> too much, but we have no idea how much that 'too much' is.  If it is a
> 5% penalty on load time, IMO it is fine for the hardening it provides.
> Maybe we could provide a build or runtime flag to bypass those checks,
> but that is an added complication that is not worth the 5% IMO.

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.

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.

There are tools to verify the binary and if there aren't they can
be written using interpreted languages like Python and ELF format
handling libraries like libelf.

---

The patch in the this thread...

https://www.sourceware.org/ml/libc-alpha/2015-07/msg00480.html

... violates the design goals of the dyanmic loader by slowing down,
even infinitesimally (since design goals are pedantic things),
the dynamic loader for the purpose of quick and efficient execution
of binaries. The additional code adds to the maintenance burden
of the dynamic loader without meeting the goals of the loader.

Arguing that it is a bug is treading on thin ice, since the bug
does not violate the design goals as stated.

We can and should discuss the design goals of the loader since
they are at the core of this discussion.

Not listed above is: What diagnostics is the loader to provide
if the ELF file is faulty? Any? A crash does not seem like a good
diagnostic? I argue that a crash is a fine diagnostic, and that
it is not the job of the dynamic loader to verify the integrity
of the binary or libraries, and that we should write other tools
for that purpose which can potentially be leveraged by the
dynamic loader running in a strict runtime verification mode
(another discussion to be had).

The course of action I recommend are based on the reality of
our situation and the true causes of crashes in ld.so which
mostly happen to be distro tooling issues and running ldd against
things which are not complete ELF files.

Next steps:

* Work to get ET_* markings for debuginfo files to avoid the
  hacks we have presently thought about adding to the dynamic
  loader.

* Work to complete eu-ldd to replace elf/ldd.bash.in, and then
  work to remove or rewrite the ld.so trace support to provide
  a developer-centric interface for debugging that is not
  restricted by a need to support ldd.

* Work to create a new project e.g. eu-verifyelf (if it doesn't
  exist) which performs strict ELF file verification and can
  for example consume the output of an ld.so trace to verify
  dlmopen/dlopen calls also (eu-ldd could also get this support).

* Lastly, add a mode where ld.so calls out to eu-verifyelf in
  some way to verify the initial binaries and libraries when
  run in some strict ELF checking mode. This cost is born once
  at startup and every time we call dlopen/dlmopen.

Cheers,
Carlos.