Use chain-loading for Linux nacl_helper

Use chain-loading for Linux nacl_helper

This replaces the nacl_helper_bootstrap program, dynamically-linked against
nacl_helper.so, with a standalone, statically-linked nacl_helper_bootstrap
program that loads the dynamic linker, instructing it in turn to load the
nacl_helper program (now a PIE rather than a DSO).

This avoids two problems with the old scheme:
1. The nacl_helper_bootstrap program remained in the dynamic linker's
   list of loaded objects, as the main executable, even though the
   memory where its .dynamic section had been was overwritten with
   the NaCl untrusted address space.  Code that traverses the list of
   all loaded objects could thus attempt to look at pointers into this
   part of memory, and be led astray.
2. nacl_helper_bootstrap's large (~1G) bss segment could cause the kernel
   to refuse to load the program because it didn't think there was enough
   free memory in the system for so large an allocation of anonymous memory.

The bootstrap program is kept very small by avoiding all use of libc
(except for memset and integer division routines needed on ARM).  It has
its own custom start-up code hand-written in assembly and its own custom
system call stubs done with hand-written GCC inline asm statements.

To avoid the second problem, the bootstrap program no longer has a large
bss.  Instead, it has a special ELF segment (i.e. PT_LOAD header) that
specifies no memory access, and a large (~1G) mapping size from the file.
This mapping is way off the end of the file, but the kernel doesn't mind
that, and since it's all a file mapping, the kernel does not do its normal
memory accounting for consuming a large amount of anonymous memory.

Unfortunately, it's impossible to get the linker to produce exactly the
right PT_LOAD header by itself.  Using a custom linker script, we get the
layout exactly how we want it and a PT_LOAD header that is almost right.
We then use a build-time helper program to munge one field of the PT_LOAD
to make it exactly what we need.

BUG= http://code.google.com/p/chromium/issues/detail?id=94147
TEST= hand-tested chromium build

R=bradchen@google.com


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=99089

[Roland McGrath, 2011-08-31 16:43:11]

This was previously reviewed at http://codereview.chromium.org/7795010/
and committed.  It then had to be reverted due to a build breakage
caused by a buildbot configuration error, which has since been
corrected.

This version also rolls in http://codereview.chromium.org/7778024/,
also previously reviewed.  That's the installer changes necessitated
by the main changes here.

[Brad Chen, 2011-08-31 17:04:01]

LGTM

[commit-bot: I haz the power, 2011-08-31 22:01:41]

No LGTM from valid reviewers yet.

[Mark Seaborn, 2011-08-31 22:15:51]

Rubber-stamp LGTM to make the commit bot happy.

[Brad Chen, 2011-08-31 22:25:21]

LGTM

[commit-bot: I haz the power, 2011-09-01 00:55:13]

Change committed as 99089