aboutsummaryrefslogtreecommitdiff
blob: 781604377dbd8ce9a3df3311f5239bac5c2e9d78 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link title="new" rel="stylesheet" href="http://www.gentoo.org/css/main.css" type="text/css">
<link REL="shortcut icon" HREF="http://www.gentoo.org/favicon.ico" TYPE="image/x-icon">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/www-gentoo-org.xml" title="Gentoo Website">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/forums-gentoo-org.xml" title="Gentoo Forums">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/bugs-gentoo-org.xml" title="Gentoo Bugzilla">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/packages-gentoo-org.xml" title="Gentoo Packages">
<link rel="search" type="application/opensearchdescription+xml" href="http://www.gentoo.org/search/archives-gentoo-org.xml" title="Gentoo List Archives">
<title>Gentoo Linux Documentation
--
  The GNU Stack Quickstart</title>
</head>
<body style="margin:0px;" bgcolor="#ffffff"><table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr><td valign="top" height="125" bgcolor="#45347b"><a href="http://www.gentoo.org/"><img border="0" src="http://www.gentoo.org/images/gtop-www.jpg" alt="Gentoo Logo"></a></td></tr>
<tr><td valign="top" align="right" colspan="1" bgcolor="#ffffff"><table border="0" cellspacing="0" cellpadding="0" width="100%"><tr>
<td width="99%" class="content" valign="top" align="left">
<br><h1>The GNU Stack Quickstart</h1>
<form name="contents" action="http://www.gentoo.org">
<b>Content</b>:
        <select name="url" size="1" OnChange="location.href=form.url.options[form.url.selectedIndex].value" style="font-family:sans-serif,Arial,Helvetica"><option value="#doc_chap1">1. Introduction</option>
<option value="#doc_chap2">2. Causes of executable stack markings</option>
<option value="#doc_chap3">3. Finding ELFs that ask for an executable stack</option>
<option value="#doc_chap4">4. What needs to be fixed</option>
<option value="#doc_chap5">5. How to fix the stack (in theory)</option>
<option value="#doc_chap6">6. How to fix the stack (in practice)</option>
<option value="#doc_chap7">7. Arch Status</option>
<option value="#doc_chap8">8. References</option></select>
</form>
<p class="chaphead"><a name="doc_chap1"></a><span class="chapnum">1.
            </span>Introduction</p>
<p>
With the rise of mainstream consumer machines with hardware stack protection 
(e.g. the <a href="http://en.wikipedia.org/wiki/NX_bit">NX bit</a> on 
amd64), we developers have to be doubly sure that our packages build with the 
correct stack settings.  Keep in mind that stack protection is an issue for all 
architectures, not just x86 or amd64.
</p>
<p>
The purpose of this document is to help package maintainers fix their packages 
when they break.  We will be focusing our attention on the GNU_STACK ELF 
marking.  ELF is simply a file format which all modern linux distros use.  An 
ELF can be an executable (say <span class="path" dir="ltr">/bin/ls</span>) or a library (say 
<span class="path" dir="ltr">/lib/libncurses.so</span>).  GNU_STACK is just an ELF program header 
which tells the system how to control the stack when the ELF is loaded into 
memory.
</p>
<p>
Before getting started, you should read through the Wikipedia entry on the 
<a href="http://en.wikipedia.org/wiki/NX_bit">NX bit</a>.  You can skip it 
of course if you're already familiar with the concept of executable versus 
non-executable stacks.
</p>
<p class="chaphead"><a name="doc_chap2"></a><span class="chapnum">2.
            </span>Causes of executable stack markings</p>
<p>
ELF files end up with executable stack markings in one of three ways:
</p>
<ol>
 <li>GCC generates code that uses executable stack</li>
 <li>an object built from assembler source includes a marking indicating to
     the linker that it needs an executable stack (the GNU-stack note set for
     executable stack)</li>
 <li>an object built from assembler source is missing the GNU-stack note;
     a very common occurrence especially for code expected to work on
     many platforms</li>
</ol>
<p>
GCC generates code to be executed on the stack when it implements a 
<a href="http://gcc.gnu.org/onlinedocs/gccint/Trampolines.html">trampoline 
for nested functions</a>.  To remove the need for an executable stack in 
this case, it is necessary to rewrite the code another way.  Sometimes this 
is relatively easy, other times not.
</p>
<p>
If an assembler source file includes a GNU-stack note that indicates it needs
an executable stack, presumably this is by design.  Again, in order to remove 
the need for an executable stack, the code probably needs to be rewritten.
</p>
<p>
If an assembler source contains no GNU-stack note, the system by default 
assumes that an executable stack may be required.  However, usually if there's 
no GNU-stack note, this is simply because the author didn't include one, 
rather than the code actually needing an executable stack.
</p>
<p>
In the first two cases above, the executable stack marking is correct, and 
should only be removed by rewriting the code to eliminate the executable 
stack requirement.  Such rewriting has to be considered on a case-by-case 
basis and is outside the scope of this document, at least for now.  Here we 
focus on the third case, where the upstream author has not indicated whether 
the assembler object needs an executable stack; fixing this means adding the 
GNU-stack note to the source to indicate an executable stack is not necessary.
</p>
<p class="chaphead"><a name="doc_chap3"></a><span class="chapnum">3.
            </span>Finding ELFs that ask for an executable stack</p>
<p>
Before you can start fixing something, you have to make sure it's broken first, 
right?  For this reason, we've developed a suite of tools named <a href="pax-utils.html">PaX Utilities</a>.  If you are not 
familiar with these utilities, you should read the <a href="pax-utils.html">PaX Utilities Guide</a> now.  Gentoo users 
can simply do <span class="code" dir="ltr">emerge pax-utils</span>.  Non-Gentoo users should be able to 
find a copy of the source tarball in the <span class="path" dir="ltr">distfiles</span> on a <a href="http://www.gentoo.org/main/en/mirrors.xml">Gentoo Mirror</a>.  Once you have the PaX 
Utilities setup on your system, we can start playing around with 
<span class="code" dir="ltr">scanelf</span>.
</p>
<p>
Let's see if your system has any ELFs that want an executable stack.
</p>
<a name="doc_chap3_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing3.1: Scan your system</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
$ <span class="code-input">scanelf -lpqe</span>
RWX --- ---  /usr/lib/opengl/xorg-x11/lib/libGL.so.1.2
RWX --- ---  /usr/lib/libcrypto.so.0.9.7
RWX --- ---  /usr/lib/libmp.so.3.1.7
RWX --- ---  /usr/lib/libSDL-1.2.so.0.7.2
RWX --- ---  /usr/lib/libsmpeg-0.4.so.0.1.3
RWX --- ---  /usr/lib/libImlib2.so.1.2.0
RWX --- ---  /usr/lib/libOSMesa.so.4.0
RWX --- ---  /usr/lib/libxvidcore.so.4.1
RWX --- ---  /usr/lib/libgmp.so.3.3.3
RWX --- ---  /usr/bin/mencoder
RWX --- ---  /usr/bin/Xorg
RWX --- ---  /usr/bin/mplayer
</pre></td></tr>
</table>
<p>
We really only need to look at the first column (which corresponds to the ELF 
GNU_STACK markings).  Most of the time, if we fix that field, all the others 
fall into place.  As we can see above, many files are marked with an 
executable stack (<span class="emphasis">RWX</span>).  We want to make sure all files are marked 
with <span class="emphasis">RW-</span>.  The large majority of the time this means the package was 
compiled incorrectly, so not much will have to be done with patching up the 
source code.
</p>
<p class="chaphead"><a name="doc_chap4"></a><span class="chapnum">4.
            </span>What needs to be fixed</p>
<p>
We now know what files need to be fixed, but what source files are causing 
this breakage?  The only way to find this out is to compile the package and 
analyze the object files before they are combined into the final executable or 
library.
</p>
<p class="secthead"><a name="doc_chap4_sect2">Fixing smpeg</a></p>
<p>
So we first have to compile smpeg before we can analyze it.
</p>
<a name="doc_chap4_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing4.1: Compiling smpeg</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
$ <span class="code-input">ebuild /usr/portage/media-libs/smpeg/smpeg-0.4.4-r6.ebuild clean unpack compile</span>
$ <span class="code-input">cd /var/tmp/portage/smpeg-0.4.4-r6/work/smpeg-0.4.4/</span>
</pre></td></tr>
</table>
<p>
Now we need to look at each object file and see if it has a 
<span class="emphasis">.note.GNU-stack</span> ELF section.  Chances are, the object which is causing 
us trouble lacks this section completely.  In that case, the compiler will 
assume that the ELF should not be restricted at all and mark it as <span class="emphasis">RWX</span>.
The <span class="code" dir="ltr">scanelf</span> utility will display output slightly different when
presented with an object that is missing the ELF section.  The <b>!WX</b>
below means that "Oh no, the GNU-stack is missing and write/execute permissions
will be used by default!"
</p>
<a name="doc_chap4_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing4.2: Locate missing .note.GNU-stack sections</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
$ <span class="code-input">scanelf -qeR .</span>
!WX --- ---  ./video/mmxflags_asm.o
!WX --- ---  ./video/mmxflags_asm.lo
!WX --- ---  ./video/mmxidct_asm.o
!WX --- ---  ./video/mmxidct_asm.lo
</pre></td></tr>
</table>
<p>
Sure enough, these objects lack the <span class="emphasis">.note.GNU-stack</span> ELF section and 
they are linked into the final <span class="path" dir="ltr">libsmpeg.so</span> library.  If we were 
to patch the source files <span class="path" dir="ltr">video/mmxflags_asm.S</span> and 
<span class="path" dir="ltr">video/mmxidct_asm.S</span> so that they contain <span class="emphasis">.note.GNU-stack</span>, 
everything would be peachy.
</p>
<p class="secthead"><a name="doc_chap4_sect3">Check objects by hand</a></p>
<p>
For fun, lets see how we could use the more common <span class="code" dir="ltr">readelf</span> utility
(which is part of the <span class="emphasis">binutils</span> package).
</p>
<a name="doc_chap4_pre3"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing4.3: Using readelf</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
<span class="code-comment">This is what the output should look like, notice the .note.GNU-stack line</span>

$ <span class="code-input">readelf -S plaympeg.o</span>
There are 12 section headers, starting at offset 0x256c:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 000040 001ede 00  AX  0   0 16
  [ 2] .rel.text         REL             00000000 0030c0 000728 08     10   1  4
  [ 3] .data             PROGBITS        00000000 001f20 000000 00  WA  0   0  4
  [ 4] .bss              NOBITS          00000000 001f20 000000 00  WA  0   0  4
  [ 5] .rodata.str1.4    PROGBITS        00000000 001f20 0003db 01 AMS  0   0  4
  [ 6] .rodata.str1.1    PROGBITS        00000000 0022fb 0001c9 01 AMS  0   0  1
  <span class="code-input">[ 7] .note.GNU-stack   PROGBITS        00000000 0024c4 000000 00      0   0  1</span>
  [ 8] .comment          PROGBITS        00000000 0024c4 00003e 00      0   0  1
  [ 9] .shstrtab         STRTAB          00000000 002502 000067 00      0   0  1
  [10] .symtab           SYMTAB          00000000 00274c 0005e0 10     11   9  4
  [11] .strtab           STRTAB          00000000 002d2c 000394 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)


<span class="code-comment">Notice how there is no .note.GNU-stack section here</span>

$ <span class="code-input">readelf -S video/mmxidct_asm.o</span>
There are 8 section headers, starting at offset 0x738:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 000034 0005ee 00  AX  0   0  4
  [ 2] .rel.text         REL             00000000 000a4c 0000f0 08      6   1  4
  [ 3] .data             PROGBITS        00000000 000630 0000d8 00  WA  0   0 16
  [ 4] .bss              NOBITS          00000000 000708 000000 00  WA  0   0  4
  [ 5] .shstrtab         STRTAB          00000000 000708 000030 00      0   0  1
  [ 6] .symtab           SYMTAB          00000000 000878 000120 10      7  17  4
  [ 7] .strtab           STRTAB          00000000 000998 0000b1 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)
</pre></td></tr>
</table>
<p class="chaphead"><a name="doc_chap5"></a><span class="chapnum">5.
            </span>How to fix the stack (in theory)</p>
<p>
When you compile source code normally, gcc takes care of adding the GNU_STACK 
markings so that the final object code is not marked with an executable 
stack unless it actually needs it.  However, if you compile assembly code,
gcc will not automatically add GNU_STACK markings.  So, the most common source
of executable stacks in ELF binaries are packages which include raw assembly
code.  Note that we're not talking about inline assembly code, but rather
files like <span class="emphasis">.S</span> which are written in pure assembler.
</p>
<p>
We can either patch each source file written in assembler and send the fixes 
upstream, or we can be lazy and simply force the package build system to 
assemble the source files with the GNU as option <span class="emphasis">--noexecstack</span> (but 
this is highly discouraged).
</p>
<p>
The advantage to patching the code is that it's easy to do, it's portable, 
and we can usually convince upstream to add it to their packages with little 
fuss.  The disadvantage to patching is that we may have to patch many many 
files.
</p>
<p>
The advantage to just using <span class="emphasis">--noexecstack</span> is that you can simply add it 
to your ebuild and be done.  The disadvantage is that the option isn't very 
portable (it won't work with non-GNU systems, and it probably won't even 
work with all GNU systems), and we can't really convince upstream to make this 
change.  Thus, the only people who see the benefit here is Gentoo users.  You 
gotta think big baby!
</p>
<p class="chaphead"><a name="doc_chap6"></a><span class="chapnum">6.
            </span>How to fix the stack (in practice)</p>
<p class="secthead"><a name="doc_chap6_sect1">Patching</a></p>
<p>
The great thing about patching is that you can copy and paste this stuff 
everywhere.  Just make sure the code will be preprocessed (e.g. the source 
file is named with <span class="emphasis">.S</span> and not <span class="emphasis">.s</span>).  Stick these code snippets 
at the end of the source file, recompile, and do a jig.
</p>
<a name="doc_chap6_pre1"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing6.1: Stack markings for GNU as (arch-independent)</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
#if defined(__linux__) &amp;&amp; defined(__ELF__)
.section .note.GNU-stack,"",%progbits
#endif
</pre></td></tr>
</table>
<a name="doc_chap6_pre2"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing6.2: Stack markings for NASM/YASM (x86/amd64-only)</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
%ifidn __OUTPUT_FORMAT__,elf
section .note.GNU-stack noalloc noexec nowrite progbits
%endif
%ifidn __OUTPUT_FORMAT__,elf32
section .note.GNU-stack noalloc noexec nowrite progbits
%endif
%ifidn __OUTPUT_FORMAT__,elf64
section .note.GNU-stack noalloc noexec nowrite progbits
%endif
</pre></td></tr>
</table>
<p class="secthead"><a name="doc_chap6_sect2">Compiling with --noexecstack</a></p>
<p>
Often times you only need to add the following code in your ebuild.  You must 
first be sure that the code does not actually require an executable stack as 
forcing this flag will break the package otherwise.
</p>
<table class="ncontent" width="100%" border="0" cellspacing="0" cellpadding="0"><tr><td bgcolor="#ffffbb"><p class="note"><b>Important: </b>
Please rethink patching before using this option.  Patching source code 
benefits a lot more people which is the goal of OSS.
</p></td></tr></table>
<a name="doc_chap6_pre3"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing6.3: Using --noexecstack</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
<span class="code-comment"># This line goes at the top of your ebuild</span>
inherit flag-o-matic

<span class="code-comment"># This line goes before CFLAGS is used (either by the ebuild or by econf/emake)</span>
append-flags -Wa,--noexecstack
</pre></td></tr>
</table>
<p>
On the off chance that you cannot assemble the files, you can tell the linker
to disable execstack stack.
</p>
<a name="doc_chap6_pre4"></a><table class="ntable" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr><td bgcolor="#7a5ada"><p class="codetitle">Code Listing6.4: Using -z noexecstack</p></td></tr>
<tr><td bgcolor="#eeeeff" align="left" dir="ltr"><pre>
<span class="code-comment"># This line goes at the top of your ebuild</span>
inherit flag-o-matic

<span class="code-comment"># This line goes before LDFLAGS is used (either by the ebuild or by econf/emake)</span>
append-ldflags -Wl,-z,noexecstack
</pre></td></tr>
</table>
<p class="secthead"><a name="doc_chap6_sect3">If all else fails ...</a></p>
<p>
If all else fails, ask around on #gentoo-dev on the irc server 
irc.freenode.net.  Or send an e-mail to the <a href="http://www.gentoo.org/main/en/lists.xml">gentoo-dev mailing list</a>.  
If no one can seem to answer your question, give me a poke either on irc 
(nickname SpanKY/vapier) or via <a href="mailto:vapier@gentoo.org">e-mail</a>.
</p>
<p class="chaphead"><a name="doc_chap7"></a><span class="chapnum">7.
            </span>Arch Status</p>
<table class="ntable">
 <tr>
<td class="infohead"><b>Arch</b></td>     <td class="infohead"><b>Status</b></td>
</tr>
 <tr>
<td class="tableinfo">alpha</td>    <td class="tableinfo">fully supported (gcc-4.4.x/glibc-2.11)</td>
</tr>
 <tr>
<td class="tableinfo">amd64</td>    <td class="tableinfo">fully supported</td>
</tr>
 <tr>
<td class="tableinfo">arm</td>      <td class="tableinfo">fully supported (gcc-4.1.x/glibc-2.5)</td>
</tr>
 <tr>
<td class="tableinfo">blackfin</td> <td class="tableinfo">fully supported (gcc-4.3+)</td>
</tr>
 <tr>
<td class="tableinfo">hppa</td>     <td class="tableinfo">gcc-3.4.x does not generate .note.GNU-stack</td>
</tr>
 <tr>
<td class="tableinfo">ia64</td>     <td class="tableinfo">fully supported (gcc-3.4.4+)</td>
</tr>
 <tr>
<td class="tableinfo">m68k</td>     <td class="tableinfo">fully supported (gcc-3.4.x)</td>
</tr>
 <tr>
<td class="tableinfo">mips</td>     <td class="tableinfo">gcc-3.4.x does not generate .note.GNU-stack</td>
</tr>
 <tr>
<td class="tableinfo">ppc</td>      <td class="tableinfo">fully supported (gcc-4.4.x/glibc-2.11)</td>
</tr>
 <tr>
<td class="tableinfo">ppc64</td>    <td class="tableinfo">fully supported (gcc-4.4.x/glibc-2.11)</td>
</tr>
 <tr>
<td class="tableinfo">s390</td>     <td class="tableinfo">fully supported</td>
</tr>
 <tr>
<td class="tableinfo">s390x</td>    <td class="tableinfo">fully supported</td>
</tr>
 <tr>
<td class="tableinfo">sh</td>       <td class="tableinfo">fully supported (gcc-3.4.x/glibc-2.5)</td>
</tr>
 <tr>
<td class="tableinfo">sparc</td>    <td class="tableinfo">fully supported</td>
</tr>
 <tr>
<td class="tableinfo">x86</td>      <td class="tableinfo">fully supported</td>
</tr>
</table>
<p class="chaphead"><a name="doc_chap8"></a><span class="chapnum">8.
            </span>References</p>
<ul>
 <li>thanks to the <a href="http://pax.grsecurity.net/">PaX team</a> for holding my hand</li>
 <li>Roland McGrath's <a href="http://www.redhat.com/archives/fedora-devel-list/2003-November/msg00838.html">brain dump</a>
</li>
 <li>
<a href="http://en.wikipedia.org/wiki/NX_bit">NX bit</a> Wikipedia entry</li>
</ul>
<br><br>
</td>
<td width="1%" bgcolor="#dddaec" valign="top"><table border="0" cellspacing="4px" cellpadding="4px">
<tr><td class="topsep" align="center"><p class="altmenu"><a title="View a printer-friendly version" class="altlink" href="gnu-stack.xml?style=printable">Print</a></p></td></tr>
<tr><td class="topsep" align="center"><p class="alttext">Updated June 11, 2011</p></td></tr>
<tr><td class="topsep" align="left"><p class="alttext"><b>Summary: </b>Handbook for proper GNU Stack management in ELF systems</p></td></tr>
<tr><td align="left" class="topsep"><p class="alttext">
 <a href="mailto:vapier@gentoo.org" class="altlink"><b>Mike Frysinger</b></a>
<br><i>Author</i><br><br>
 <a href="mailto:solar@gentoo.org" class="altlink"><b>solar</b></a>
<br><i>Author</i><br><br>
 <a href="mailto:pageexec@freemail.hu" class="altlink"><b>The PaX team</b></a>
<br><i>Contributor</i><br><br>
 <a href="mailto:g2@kevquinn.com" class="altlink"><b>Kevin F. Quinn</b></a>
<br><i>Contributor</i><br><br>
 <a href="mailto:klondike@gentoo.org" class="altlink"><b>klondike</b></a>
<br><i>Contributor</i><br></p></td></tr>
<tr lang="en"><td align="center" class="topsep">
<p class="alttext"><b>Donate</b> to support our development efforts.
        </p>
<form action="https://www.paypal.com/cgi-bin/webscr" method="post">
<input type="hidden" name="cmd" value="_xclick"><input type="hidden" name="business" value="paypal@gentoo.org"><input type="hidden" name="item_name" value="Gentoo Linux Support"><input type="hidden" name="item_number" value="1000"><input type="hidden" name="image_url" value="http://www.gentoo.org/images/paypal.png"><input type="hidden" name="no_shipping" value="1"><input type="hidden" name="return" value="http://www.gentoo.org"><input type="hidden" name="cancel_return" value="http://www.gentoo.org"><input type="image" src="http://images.paypal.com/images/x-click-but21.gif" name="submit" alt="Donate to Gentoo">
</form>
</td></tr>
<tr lang="en"><td align="center"><iframe src="http://sidebar.gentoo.org" scrolling="no" width="125" height="850" frameborder="0" style="border:0px padding:0x" marginwidth="0" marginheight="0"><p>Your browser does not support iframes.</p></iframe></td></tr>
</table></td>
</tr></table></td></tr>
<tr><td colspan="2" align="right" class="infohead">
Copyright 2001-2011 Gentoo Foundation, Inc. Questions, Comments? <a class="highlight" href="http://www.gentoo.org/main/en/contact.xml">Contact us</a>.
</td></tr>
</table></body>
</html>