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

Side by Side Diff: chrome/nacl/nacl_helper_bootstrap_linux.x

Issue 7776034: Use chain-loading for Linux nacl_helper (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src
Patch Set: rebased Created 9 years, 3 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch | Annotate | Revision Log
OLDNEW
(Empty)
1 /* Copyright (c) 2011 The Chromium Authors. All rights reserved.
2 * Use of this source code is governed by a BSD-style license that can be
3 * found in the LICENSE file.
4 *
5 * This is a custom linker script used to build nacl_helper_bootstrap.
6 * It has a very special layout. This script will only work with input
7 * that is kept extremely minimal. If there are unexpected input sections
8 * not named here, the result will not be correct.
9 *
10 * We need to use a standalone loader program rather than just using a
11 * dynamically-linked program here because its entire address space will be
12 * taken over for the NaCl untrusted address space. A normal program would
13 * cause dynamic linker data structures to point to its .dynamic section,
14 * which is no longer available after startup.
15 *
16 * We need this special layout (and the nacl_helper_bootstrap_munge_phdr
17 * step) because simply having bss space large enough to reserve the
18 * address space would cause the kernel loader to think we're using that
19 * much anonymous memory and refuse to execute the program on a machine
20 * with not much memory available.
21 */
22
23 /*
24 * Set the entry point to the symbol called _start, which we define in assembly.
25 */
26 ENTRY(_start)
27
28 /*
29 * This is the address where the program text starts.
30 * We set this as low as we think we can get away with.
31 * The common settings for sysctl vm.mmap_min_addr range from 4k to 64k.
32 */
33 TEXT_START = 0x10000;
34
35 /*
36 * This is the top of the range we are trying to reserve, which is 1G
37 * for x86-32 and ARM. For an x86-64 zero-based sandbox, this really
38 * needs to be 36G.
39 */
40 RESERVE_TOP = 1 << 30;
41
42 /*
43 * We specify the program headers we want explicitly, to get the layout
44 * exactly right and to give the "reserve" segment p_flags of zero, so
45 * that it gets mapped as PROT_NONE.
46 */
47 PHDRS {
48 text PT_LOAD FILEHDR PHDRS;
49 reserve PT_LOAD FLAGS(0);
50 stack PT_GNU_STACK FLAGS(6); /* RW, no E */
51 }
52
53 /*
54 * Now we lay out the sections across those segments.
55 */
56 SECTIONS {
57 /*
58 * Here is the program itself.
59 */
60 .text TEXT_START + SIZEOF_HEADERS : {
61 *(.note.gnu.build-id)
62 *(.text*)
63 *(.rodata*)
64 *(.eh_frame*)
65 } :text
66 etext = .;
67
68 /*
69 * Now we move up to the next p_align increment, and place the dummy
70 * segment there. The linker emits this segment with the p_vaddr and
71 * p_memsz we want, which reserves the address space. But the linker
72 * gives it a p_filesz of zero. We have to edit the phdr after link
73 * time to give it a p_filesz matching its p_memsz. That way, the
74 * kernel doesn't think we are preallocating a huge amount of memory.
75 * It just maps it from the file, i.e. way off the end of the file,
76 * which is perfect for reserving the address space.
77 */
78 . = ALIGN(CONSTANT(COMMONPAGESIZE));
79 RESERVE_START = .;
80 .reserve : {
81 . = RESERVE_TOP - RESERVE_START;
82 } :reserve
83
84 /*
85 * These are empty input sections the linker generates.
86 * If we don't discard them, they pollute the flags in the output segment.
87 */
88 /DISCARD/ : {
89 *(.iplt)
90 *(.rel*)
91 *(.igot.plt)
92 }
93 }
OLDNEW
« no previous file with comments | « chrome/nacl/nacl_helper_bootstrap_linux.c ('k') | chrome/nacl/nacl_helper_bootstrap_munge_phdr.c » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698