Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(25)

Issue 7811013: Revert 98909 - Use chain-loading for Linux nacl_helper (Closed)

Created:
9 years, 3 months ago by jar (doing other things)
Modified:
9 years, 3 months ago
CC:
chromium-reviews, native-client-reviews_googlegroups.com
Visibility:
Public.

Description

Revert 98909 - 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, invoked with --nacl-linux-helper R=bradchen@google.com,mseaborn@chromium.org Review URL: http://codereview.chromium.org/7795010 TBR=mcgrathr@chromium.org Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=98910

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+65 lines, -733 lines) Patch
M build/install-build-deps.sh View 1 chunk +1 line, -1 line 0 comments Download
M chrome/common/chrome_paths.h View 1 chunk +0 lines, -1 line 0 comments Download
M chrome/common/chrome_paths.cc View 2 chunks +1 line, -8 lines 0 comments Download
M chrome/nacl.gypi View 3 chunks +23 lines, -93 lines 0 comments Download
M chrome/nacl/nacl_fork_delegate_linux.cc View 2 chunks +8 lines, -10 lines 0 comments Download
MM chrome/nacl/nacl_helper_bootstrap_linux.c View 1 chunk +14 lines, -419 lines 0 comments Download
D chrome/nacl/nacl_helper_bootstrap_linux.x View 1 chunk +0 lines, -93 lines 0 comments Download
D chrome/nacl/nacl_helper_bootstrap_munge_phdr.c View 1 chunk +0 lines, -66 lines 0 comments Download
D chrome/nacl/nacl_helper_bootstrap_munge_phdr.py View 1 chunk +0 lines, -36 lines 0 comments Download
A + chrome/nacl/nacl_helper_exports.txt View 0 chunks +-1 lines, --1 lines 0 comments Download
M chrome/nacl/nacl_helper_linux.cc View 2 chunks +19 lines, -7 lines 0 comments Download

Messages

Total messages: 3 (0 generated)
jar (doing other things)
9 years, 3 months ago (2011-08-31 01:45:57 UTC) #1
Brad Chen
It looks like this bot might not have gotten the libelf package install that the ...
9 years, 3 months ago (2011-08-31 03:59:02 UTC) #2
Brad Chen
9 years, 3 months ago (2011-08-31 03:59:03 UTC) #3
It looks like this bot might not have gotten the libelf package install that
the other bots had. I sent a note on the related thread so hopefully the
infrastructure team will find and fix a problem and then we can have another
go tomorrow.

Brad

On Tue, Aug 30, 2011 at 6:45 PM, <jar@chromium.org> wrote:

> Reviewers: Roland McGrath,
>
> Description:
> Revert 98909 - 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<http://code.goog...
> TEST= hand-tested chromium build, invoked with --nacl-linux-helper
>
> R=bradchen@google.com,mseaborn**@chromium.org <mseaborn@chromium.org>
>
>
> Review URL:
http://codereview.chromium.**org/7795010<http://codereview.chromium.org/7795010>
>
> TBR=mcgrathr@chromium.org
>
> Please review this at
http://codereview.chromium.**org/7811013/<http://codereview.chromium.org/7811...
>
> SVN Base:
svn://svn.chromium.org/chrome/**trunk/src/<http://svn.chromium.org/chrome/trunk/src/>
>
> Affected files:
>  M     build/install-build-deps.sh
>  M     chrome/common/chrome_paths.h
>  M     chrome/common/chrome_paths.cc
>  M     chrome/nacl.gypi
>  M     chrome/nacl/nacl_fork_**delegate_linux.cc
>  MM    chrome/nacl/nacl_helper_**bootstrap_linux.c
>  D     chrome/nacl/nacl_helper_**bootstrap_linux.x
>  D     chrome/nacl/nacl_helper_**bootstrap_munge_phdr.c
>  D     chrome/nacl/nacl_helper_**bootstrap_munge_phdr.py
>  A  +  chrome/nacl/nacl_helper_**exports.txt
>  M     chrome/nacl/nacl_helper_linux.**cc
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Native-Client-Reviews" group.
> To post to this group, send email to native-client-reviews@**
> googlegroups.com <native-client-reviews@googlegroups.com>.
> To unsubscribe from this group, send email to native-client-reviews+**
>
unsubscribe@googlegroups.com<native-client-reviews%2Bunsubscribe@googlegroups...
> .
> For more options, visit this group at http://groups.google.com/**
>
group/native-client-reviews?**hl=en<http://groups.google.com/group/native-client-reviews?hl=en>
> .
>
>

Powered by Google App Engine
This is Rietveld 408576698