diff options
| author | Rob Landley <rob@landley.net> | 2008-09-15 10:24:22 +0000 | 
|---|---|---|
| committer | Rob Landley <rob@landley.net> | 2008-09-15 10:24:22 +0000 | 
| commit | 15ffa43fafc8a2dfd1e69d8d6b05ef55a06ccfbe (patch) | |
| tree | 30be235032858a6d0de490635fa65dd37ac1ff03 | |
| parent | c9db9e50e6d86816d3304aba958d426aace90443 (diff) | |
Make menuconfig help bigger and fluffier.
| -rw-r--r-- | extra/Configs/Config.in | 99 | 
1 files changed, 79 insertions, 20 deletions
diff --git a/extra/Configs/Config.in b/extra/Configs/Config.in index a56292de8..4aca400b5 100644 --- a/extra/Configs/Config.in +++ b/extra/Configs/Config.in @@ -1062,24 +1062,29 @@ endif  menu "String and Stdio Support"  config UCLIBC_HAS_STRING_GENERIC_OPT -	bool "Use glibc generic string functions" +	bool "Use faster (but larger) generic string functions"  	default y  	help  	  Answer Y to use the (tweaked) glibc generic string functions. +  	  In general, they are faster (but 3-5K larger) than the base  	  uClibc string functions which are optimized solely for size.  	  Many people will answer Y.  config UCLIBC_HAS_STRING_ARCH_OPT -	bool "Use arch-specific string functions" +	bool "Use arch-specific assembly string functions (where available)"  	default y  	help -	  Answer Y to use the arch-specific string functions instead of the -	  base uClibc versions, which are optimized exclusively for size. +	  Answer Y to use any archtecture-specific assembly language string +	  functions available for this target plaform. + +	  Note that assembly implementations are not available for all string +	  functions, so some generic (written in C) string functions may +	  still be used. -	  Most people will answer Y, as this has been default behavior -	  for some time. +	  These are small and fast, the only reason _not_ to say Y here is +	  for debugging purposes.  config UCLIBC_HAS_CTYPE_TABLES  	bool "Use Table Versions Of 'ctype.h' Functions." @@ -1727,14 +1732,24 @@ config HAVE_NO_SSP  	default n  config UCLIBC_HAS_SSP -	bool "Support for propolice smashing stack protector" +	bool "Support for GCC stack smashing protector"  	depends on !HAVE_NO_SSP  	default n  	help -	  Add propolice smashing stack protector to the library. -	  This requires GCC 4.1, supporting the -fstack-protector[-all] -	  options. GCC does not have to provide libssp, the needed -	  functions are added to ldso/libc instead. +	  Add code to support GCC's -fstack-protector[-all] option to uClibc. +	  This requires GCC 4.1 or newer.  GCC does not have to provide libssp, +	  the needed functions are added to ldso/libc instead. + +	  GCC's stack protector is a reimplementation of IBM's propolice. +	  See http://www.trl.ibm.com/projects/security/ssp/ and +	  http://www.linuxfromscratch.org/hints/downloads/files/ssp.txt +	  for details. + +	  Note that NOEXECSTACK on a kernel with address space randomization +	  is generally sufficient to prevent most buffer overflow exploits +	  without increasing code size.  This option essentially adds debugging +	  code to catch them. +  	  Most people will answer N.  config UCLIBC_HAS_SSP_COMPAT @@ -1743,12 +1758,15 @@ config UCLIBC_HAS_SSP_COMPAT  	default n  	help  	  Add gcc-3.x propolice smashing stack protector to the library. +  	  This requires a patched version of GCC, supporting the  	  -fstack-protector[-all] options, with the __guard and  	  __stack_smash_handler functions removed from libgcc.  	  These functions are added to ldso/libc instead. +  	  More information at:  	  <http://www.research.ibm.com/trl/projects/security/ssp/> +  	  Most people will answer N.  config SSP_QUICK_CANARY @@ -1785,33 +1803,74 @@ config PROPOLICE_BLOCK_SEGV  endchoice  config UCLIBC_BUILD_SSP -	bool "Build uClibc with propolice protection" +	bool "Build uClibc with -fstack-protector"  	depends on UCLIBC_HAS_SSP  	default n  	help -	  Build all libraries and executables with propolice protection enabled. +	  Build all uClibc libraries and executables with -fstack-protector, +	  adding extra stack overflow checking to most uClibc functions.  config UCLIBC_BUILD_RELRO -	bool "Build uClibc with RELRO" +	bool "Build uClibc with linker option -z RELRO"  	depends on HAVE_SHARED  	default y  	help -	  Build all libraries and executables with -z relro. +	  Build all libraries and executables with "ld -z relro". + +	  This tells the linker to mark chunks of an executable or shared +	  library read-only after applying dynamic relocations.  (This comes +	  up when a global const variable is initialized to the address of a +	  function or the value of another global variable.) + +	  This is a fairly obscure option the ld man page doesn't even bother +	  to document properly.  It's a security paranoia issue that's more +	  likely to consume memory (by allocating an extra page) rather than +	  save it. + +	  This is explained in more depth at +	  http://www.airs.com/blog/archives/189 + +	  Nobody is likely to care whether you say Y or N here.  config UCLIBC_BUILD_NOW -	bool "Build uClibc with NOW" +	bool "Build uClibc with linker option -z NOW"  	depends on HAVE_SHARED  	default n  	help -	  Build all libraries and executables with -z now. +	  Build all libraries and executables with "ld -z now". + +	  This tells the linker to resolve all symbols when the library is +	  first loaded, rather than when each function is first called.  This +	  increases start-up latency by a few microseconds and may do +	  unnecessary work (resolving symbols that are never used), but the +	  realtime people like it for making microbenchmark timings slightly +	  more predictable and in some cases it can be slightly faster due to +	  CPU cache behavior (not having to fault the linker back in to do +	  lazy symbol resolution). + +	  Most people can't tell the difference between selecting Y or N here.  config UCLIBC_BUILD_NOEXECSTACK  	bool "Build uClibc with noexecstack marking"  	default y  	help -	  Mark all assembler files as noexecstack. This will result in marking -	  all libraries and executables built against uClibc not requiring -	  executable stack. +	  Mark all assembler files as noexecstack, which will mark uClibc +	  as not requiring an executable stack.  (This doesn't prevent other +	  files you link against from claiming to need an executable stack, it +	  just won't cause uClibc to request it unnecessarily.) + +	  This is a security thing to make buffer overflows harder to exploit. +	  By itself, it's kind of useless, as Linus Torvalds explained in 1998: +	  http://old.lwn.net/1998/0806/a/linus-noexec.html + +	  It only actually provides any security when combined with address +	  space randomization, explained here: http://lwn.net/Articles/121845/ + +	  Address space randomization is on by default in current linux +	  kernels (although it can be disabled using the option +	  CONFIG_COMPAT_BRK). + +	  You should probably say Y.  endmenu  | 
