[Devil-linux-commit] build/scripts/configuration/help gcc.help,1.2,1.3

[<smi...@us...>]

Update of /cvsroot/devil-linux/build/scripts/configuration/help
In directory sc8-pr-cvs1:/tmp/cvs-serv3585/scripts/configuration/help

Modified Files:
	gcc.help 
Log Message:
- added support for compiling all executables as ET_DYN


Index: gcc.help
===================================================================
RCS file: /cvsroot/devil-linux/build/scripts/configuration/help/gcc.help,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- gcc.help	24 Dec 2003 23:14:37 -0000	1.2
+++ gcc.help	27 Dec 2003 02:52:51 -0000	1.3
@@ -9,3 +9,26 @@
 
 CONFIG_GCC_STACK_PROTECTOR
   This is a C and C++ security extension for GCC.
+
+CONFIG_GCC_ET_DYN
+   Makes use of the Address Space Layout Randomization feature of PAX.
+  
+   Quotes out of the README file:
+  
+   One of the features of PaX is Address Space Layout Randomization (ASLR)
+   that allows the kernel to randomize the addresses of various areas in
+   the task's address space. While most of ASLR requires no changes in
+   userland, randomizing the main executable's base address presents a
+   challenge as traditionally such ELF executables of the ET_EXEC kind
+   do not contain enough relocation information. Nevertheless, PaX provides
+   two ways to solve this problem: RANDEXEC and RANDMMAP.
+
+   RANDMMAP on the other hand works on ELF files of the ET_DYN kind which is
+   normally used for dynamically linkable libraries. This approach has none
+   of the drawbacks that plague RANDEXEC because such ET_DYN ELF files have
+   enough relocation information and the dynamic linker has no problem with
+   relocating them (and there is no performance penalty at runtime), nor is
+   there a chance for false positive attack detections as none is done in the
+   first place. This means that protecting against the return-to-libc style
+   attack (in case the information about the randomization can leak to the
+   attacker) requires other approaches, which is not discussed here.