diff options
| author | mcgrathr@chromium.org <mcgrathr@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-09-01 00:55:05 +0000 |
|---|---|---|
| committer | mcgrathr@chromium.org <mcgrathr@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-09-01 00:55:05 +0000 |
| commit | 867a46429c82870b18e22b082fe5455721539f43 (patch) | |
| tree | 66e5b30a3a3b620f6dc8d96ef49dc4a21e34bdb4 /build/install-build-deps.sh | |
| parent | 9ad3f0c227121fc3bb55723894cf21254b566de7 (diff) | |
| download | chromium_src-867a46429c82870b18e22b082fe5455721539f43.zip chromium_src-867a46429c82870b18e22b082fe5455721539f43.tar.gz chromium_src-867a46429c82870b18e22b082fe5455721539f43.tar.bz2 | |
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
Review URL: http://codereview.chromium.org/7776034
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@99089 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'build/install-build-deps.sh')
| -rwxr-xr-x | build/install-build-deps.sh | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/build/install-build-deps.sh b/build/install-build-deps.sh index c21faf3..42fa4c8 100755 --- a/build/install-build-deps.sh +++ b/build/install-build-deps.sh @@ -103,7 +103,7 @@ chromeos_dev_list="libpulse-dev" # Packages need for development dev_list="apache2.2-bin bison fakeroot flex g++ gperf language-pack-fr libapache2-mod-php5 libasound2-dev libbz2-dev libcairo2-dev - libcups2-dev libdbus-glib-1-dev libgconf2-dev + libcups2-dev libdbus-glib-1-dev libelf-dev libgconf2-dev libgl1-mesa-dev libglu1-mesa-dev libglib2.0-dev libgnome-keyring-dev libgtk2.0-dev libjpeg62-dev libkrb5-dev libnspr4-dev libnss3-dev libpam0g-dev libsctp-dev libsqlite3-dev libxslt1-dev libxss-dev |