--- zzzz-none-000/linux-2.6.19.2/security/Kconfig	2007-01-10 19:10:37.000000000 +0000
+++ davinci-8020-5505/linux-2.6.19.2/security/Kconfig	2007-01-19 14:42:56.000000000 +0000
@@ -4,6 +4,432 @@
 
 menu "Security options"
 
+menu "PaX"
+
+config PAX
+	bool "Enable various PaX features"
+	depends on GRKERNSEC && (ALPHA || ARM || IA64 || MIPS32 || MIPS64 || PARISC || PPC32 || PPC64 || SPARC32 || SPARC64 || X86 || X86_64)
+	help
+	  This allows you to enable various PaX features.  PaX adds
+	  intrusion prevention mechanisms to the kernel that reduce
+	  the risks posed by exploitable memory corruption bugs.
+
+menu "PaX Control"
+	depends on PAX
+
+config PAX_SOFTMODE
+	bool 'Support soft mode'
+	help
+	  Enabling this option will allow you to run PaX in soft mode, that
+	  is, PaX features will not be enforced by default, only on executables
+	  marked explicitly.  You must also enable PT_PAX_FLAGS support as it
+	  is the only way to mark executables for soft mode use.
+
+	  Soft mode can be activated by using the "pax_softmode=1" kernel command
+	  line option on boot.  Furthermore you can control various PaX features
+	  at runtime via the entries in /proc/sys/kernel/pax.
+
+config PAX_EI_PAX
+	bool 'Use legacy ELF header marking'
+	help
+	  Enabling this option will allow you to control PaX features on
+	  a per executable basis via the 'chpax' utility available at
+	  http://pax.grsecurity.net/.  The control flags will be read from
+	  an otherwise reserved part of the ELF header.  This marking has
+	  numerous drawbacks (no support for soft-mode, toolchain does not
+	  know about the non-standard use of the ELF header) therefore it
+	  has been deprecated in favour of PT_PAX_FLAGS support.
+
+	  If you have applications not marked by the PT_PAX_FLAGS ELF
+	  program header then you MUST enable this option otherwise they
+	  will not get any protection.
+
+	  Note that if you enable PT_PAX_FLAGS marking support as well,
+	  the PT_PAX_FLAG marks will override the legacy EI_PAX marks.
+
+config PAX_PT_PAX_FLAGS
+	bool 'Use ELF program header marking'
+	help
+	  Enabling this option will allow you to control PaX features on
+	  a per executable basis via the 'paxctl' utility available at
+	  http://pax.grsecurity.net/.  The control flags will be read from
+	  a PaX specific ELF program header (PT_PAX_FLAGS).  This marking
+	  has the benefits of supporting both soft mode and being fully
+	  integrated into the toolchain (the binutils patch is available
+	  from http://pax.grsecurity.net).
+
+	  If you have applications not marked by the PT_PAX_FLAGS ELF
+	  program header then you MUST enable the EI_PAX marking support
+	  otherwise they will not get any protection.
+
+	  Note that if you enable the legacy EI_PAX marking support as well,
+	  the EI_PAX marks will be overridden by the PT_PAX_FLAGS marks.
+
+choice
+	prompt 'MAC system integration'
+	default PAX_NO_ACL_FLAGS
+	help
+	  Mandatory Access Control systems have the option of controlling
+	  PaX flags on a per executable basis, choose the method supported
+	  by your particular system.
+
+	  - "none": if your MAC system does not interact with PaX,
+	  - "direct": if your MAC system defines pax_set_flags() itself,
+	  - "hook": if your MAC system uses the pax_set_flags_func callback.
+
+	  NOTE: this option is for developers/integrators only.
+
+config PAX_NO_ACL_FLAGS
+	bool 'none'
+
+config PAX_HAVE_ACL_FLAGS
+	bool 'direct'
+
+config PAX_HOOK_ACL_FLAGS
+	bool 'hook'
+endchoice
+
+endmenu
+
+menu "Non-executable pages"
+	depends on PAX
+
+config PAX_NOEXEC
+	bool "Enforce non-executable pages"
+	depends on (PAX_EI_PAX || PAX_PT_PAX_FLAGS || PAX_HAVE_ACL_FLAGS || PAX_HOOK_ACL_FLAGS) && (ALPHA || IA64 || MIPS32 || MIPS64 || PARISC || PPC32 || PPC64 || SPARC32 || SPARC64 || X86 || X86_64)
+	help
+	  By design some architectures do not allow for protecting memory
+	  pages against execution or even if they do, Linux does not make
+	  use of this feature.  In practice this means that if a page is
+	  readable (such as the stack or heap) it is also executable.
+
+	  There is a well known exploit technique that makes use of this
+	  fact and a common programming mistake where an attacker can
+	  introduce code of his choice somewhere in the attacked program's
+	  memory (typically the stack or the heap) and then execute it.
+
+	  If the attacked program was running with different (typically
+	  higher) privileges than that of the attacker, then he can elevate
+	  his own privilege level (e.g. get a root shell, write to files for
+	  which he does not have write access to, etc).
+
+	  Enabling this option will let you choose from various features
+	  that prevent the injection and execution of 'foreign' code in
+	  a program.
+
+	  This will also break programs that rely on the old behaviour and
+	  expect that dynamically allocated memory via the malloc() family
+	  of functions is executable (which it is not).  Notable examples
+	  are the XFree86 4.x server, the java runtime and wine.
+
+config PAX_PAGEEXEC
+	bool "Paging based non-executable pages"
+	depends on !COMPAT_VDSO && PAX_NOEXEC && (!X86_32 || M586 || M586TSC || M586MMX || M686 || MPENTIUMII || MPENTIUMIII || MPENTIUMM || MPENTIUM4 || MK7 || MK8 || MWINCHIPC6 || MWINCHIP2 || MWINCHIP3D || MVIAC3_2)
+	help
+	  This implementation is based on the paging feature of the CPU.
+	  On i386 and ppc there is a variable but usually low performance
+	  impact on applications.  On alpha, ia64, parisc, sparc, sparc64
+	  and x86_64 there is no performance impact.
+
+config PAX_SEGMEXEC
+	bool "Segmentation based non-executable pages"
+	depends on !COMPAT_VDSO && PAX_NOEXEC && X86_32
+	help
+	  This implementation is based on the segmentation feature of the
+	  CPU and has little performance impact, however applications will
+	  be limited to a 1.5 GB address space instead of the normal 3 GB.
+
+choice
+	prompt "Default non-executable page method"
+	depends on PAX_PAGEEXEC && PAX_SEGMEXEC
+	default PAX_DEFAULT_SEGMEXEC
+	help
+	  Select the default non-executable page method applied to applications
+	  that do not select one themselves.
+
+config	PAX_DEFAULT_PAGEEXEC
+	bool "PAGEEXEC"
+
+config	PAX_DEFAULT_SEGMEXEC
+	bool "SEGMEXEC"
+endchoice
+
+config PAX_EMUTRAMP
+	bool "Emulate trampolines" if (PAX_PAGEEXEC || PAX_SEGMEXEC) && (PARISC || PPC32 || X86_32)
+	default y if PARISC || PPC32
+	help
+	  There are some programs and libraries that for one reason or
+	  another attempt to execute special small code snippets from
+	  non-executable memory pages.  Most notable examples are the
+	  signal handler return code generated by the kernel itself and
+	  the GCC trampolines.
+
+	  If you enabled CONFIG_PAX_PAGEEXEC or CONFIG_PAX_SEGMEXEC then
+	  such programs will no longer work under your kernel.
+
+	  As a remedy you can say Y here and use the 'chpax' or 'paxctl'
+	  utilities to enable trampoline emulation for the affected programs
+	  yet still have the protection provided by the non-executable pages.
+
+	  On parisc and ppc you MUST enable this option and EMUSIGRT as
+	  well, otherwise your system will not even boot.
+
+	  Alternatively you can say N here and use the 'chpax' or 'paxctl'
+	  utilities to disable CONFIG_PAX_PAGEEXEC and CONFIG_PAX_SEGMEXEC
+	  for the affected files.
+
+	  NOTE: enabling this feature *may* open up a loophole in the
+	  protection provided by non-executable pages that an attacker
+	  could abuse.  Therefore the best solution is to not have any
+	  files on your system that would require this option.  This can
+	  be achieved by not using libc5 (which relies on the kernel
+	  signal handler return code) and not using or rewriting programs
+	  that make use of the nested function implementation of GCC.
+	  Skilled users can just fix GCC itself so that it implements
+	  nested function calls in a way that does not interfere with PaX.
+
+config PAX_EMUSIGRT
+	bool "Automatically emulate sigreturn trampolines"
+	depends on PAX_EMUTRAMP && (PARISC || PPC32)
+	default y
+	help
+	  Enabling this option will have the kernel automatically detect
+	  and emulate signal return trampolines executing on the stack
+	  that would otherwise lead to task termination.
+
+	  This solution is intended as a temporary one for users with
+	  legacy versions of libc (libc5, glibc 2.0, uClibc before 0.9.17,
+	  Modula-3 runtime, etc) or executables linked to such, basically
+	  everything that does not specify its own SA_RESTORER function in
+	  normal executable memory like glibc 2.1+ does.
+
+	  On parisc and ppc you MUST enable this option, otherwise your
+	  system will not even boot.
+
+	  NOTE: this feature cannot be disabled on a per executable basis
+	  and since it *does* open up a loophole in the protection provided
+	  by non-executable pages, the best solution is to not have any
+	  files on your system that would require this option.
+
+config PAX_MPROTECT
+	bool "Restrict mprotect()"
+	depends on (PAX_PAGEEXEC || PAX_SEGMEXEC) && !PPC64
+	help
+	  Enabling this option will prevent programs from
+	   - changing the executable status of memory pages that were
+	     not originally created as executable,
+	   - making read-only executable pages writable again,
+	   - creating executable pages from anonymous memory.
+
+	  You should say Y here to complete the protection provided by
+	  the enforcement of non-executable pages.
+
+	  NOTE: you can use the 'chpax' or 'paxctl' utilities to control
+	  this feature on a per file basis.
+
+config PAX_NOELFRELOCS
+	bool "Disallow ELF text relocations"
+	depends on PAX_MPROTECT && !PAX_ETEXECRELOCS && (IA64 || X86 || X86_64)
+	help
+	  Non-executable pages and mprotect() restrictions are effective
+	  in preventing the introduction of new executable code into an
+	  attacked task's address space.  There remain only two venues
+	  for this kind of attack: if the attacker can execute already
+	  existing code in the attacked task then he can either have it
+	  create and mmap() a file containing his code or have it mmap()
+	  an already existing ELF library that does not have position
+	  independent code in it and use mprotect() on it to make it
+	  writable and copy his code there.  While protecting against
+	  the former approach is beyond PaX, the latter can be prevented
+	  by having only PIC ELF libraries on one's system (which do not
+	  need to relocate their code).  If you are sure this is your case,
+	  then enable this option otherwise be careful as you may not even
+	  be able to boot or log on your system (for example, some PAM
+	  modules are erroneously compiled as non-PIC by default).
+
+	  NOTE: if you are using dynamic ELF executables (as suggested
+	  when using ASLR) then you must have made sure that you linked
+	  your files using the PIC version of crt1 (the et_dyn.tar.gz package
+	  referenced there has already been updated to support this).
+
+config PAX_ETEXECRELOCS
+	bool "Allow ELF ET_EXEC text relocations"
+	depends on PAX_MPROTECT && (ALPHA || IA64 || PARISC)
+	default y
+	help
+	  On some architectures there are incorrectly created applications
+	  that require text relocations and would not work without enabling
+	  this option.  If you are an alpha, ia64 or parisc user, you should
+	  enable this option and disable it once you have made sure that
+	  none of your applications need it.
+
+config PAX_EMUPLT
+	bool "Automatically emulate ELF PLT"
+	depends on PAX_MPROTECT && (ALPHA || PARISC || PPC32 || SPARC32 || SPARC64)
+	default y
+	help
+	  Enabling this option will have the kernel automatically detect
+	  and emulate the Procedure Linkage Table entries in ELF files.
+	  On some architectures such entries are in writable memory, and
+	  become non-executable leading to task termination.  Therefore
+	  it is mandatory that you enable this option on alpha, parisc, ppc,
+	  sparc and sparc64, otherwise your system would not even boot.
+
+	  NOTE: this feature *does* open up a loophole in the protection
+	  provided by the non-executable pages, therefore the proper
+	  solution is to modify the toolchain to produce a PLT that does
+	  not need to be writable.
+
+config PAX_DLRESOLVE
+	bool
+	depends on PAX_EMUPLT && (SPARC32 || SPARC64)
+	default y
+
+config PAX_SYSCALL
+	bool
+	depends on PAX_PAGEEXEC && PPC32
+	default y
+
+config PAX_KERNEXEC
+	bool "Enforce non-executable kernel pages"
+	depends on PAX_NOEXEC && X86_32 && !HOTPLUG_PCI_COMPAQ_NVRAM && !PCI_BIOS && !EFI && !COMPAT_VDSO && X86_WP_WORKS_OK
+	help
+	  This is the kernel land equivalent of PAGEEXEC and MPROTECT,
+	  that is, enabling this option will make it harder to inject
+	  and execute 'foreign' code in kernel memory itself.
+
+endmenu
+
+menu "Address Space Layout Randomization"
+	depends on PAX
+
+config PAX_ASLR
+	bool "Address Space Layout Randomization"
+	depends on PAX_EI_PAX || PAX_PT_PAX_FLAGS || PAX_HAVE_ACL_FLAGS || PAX_HOOK_ACL_FLAGS
+	help
+	  Many if not most exploit techniques rely on the knowledge of
+	  certain addresses in the attacked program.  The following options
+	  will allow the kernel to apply a certain amount of randomization
+	  to specific parts of the program thereby forcing an attacker to
+	  guess them in most cases.  Any failed guess will most likely crash
+	  the attacked program which allows the kernel to detect such attempts
+	  and react on them.  PaX itself provides no reaction mechanisms,
+	  instead it is strongly encouraged that you make use of Nergal's
+	  segvguard (ftp://ftp.pl.openwall.com/misc/segvguard/) or grsecurity's
+	  (http://www.grsecurity.net/) built-in crash detection features or
+	  develop one yourself.
+
+	  By saying Y here you can choose to randomize the following areas:
+	   - top of the task's kernel stack
+	   - top of the task's userland stack
+	   - base address for mmap() requests that do not specify one
+	     (this includes all libraries)
+	   - base address of the main executable
+
+	  It is strongly recommended to say Y here as address space layout
+	  randomization has negligible impact on performance yet it provides
+	  a very effective protection.
+
+	  NOTE: you can use the 'chpax' or 'paxctl' utilities to control
+	  this feature on a per file basis.
+
+config PAX_RANDKSTACK
+	bool "Randomize kernel stack base"
+	depends on PAX_ASLR && X86_TSC && X86_32
+	help
+	  By saying Y here the kernel will randomize every task's kernel
+	  stack on every system call.  This will not only force an attacker
+	  to guess it but also prevent him from making use of possible
+	  leaked information about it.
+
+	  Since the kernel stack is a rather scarce resource, randomization
+	  may cause unexpected stack overflows, therefore you should very
+	  carefully test your system.  Note that once enabled in the kernel
+	  configuration, this feature cannot be disabled on a per file basis.
+
+config PAX_RANDUSTACK
+	bool "Randomize user stack base"
+	depends on PAX_ASLR
+	help
+	  By saying Y here the kernel will randomize every task's userland
+	  stack.  The randomization is done in two steps where the second
+	  one may apply a big amount of shift to the top of the stack and
+	  cause problems for programs that want to use lots of memory (more
+	  than 2.5 GB if SEGMEXEC is not active, or 1.25 GB when it is).
+	  For this reason the second step can be controlled by 'chpax' or
+	  'paxctl' on a per file basis.
+
+config PAX_RANDMMAP
+	bool "Randomize mmap() base"
+	depends on PAX_ASLR
+	help
+	  By saying Y here the kernel will use a randomized base address for
+	  mmap() requests that do not specify one themselves.  As a result
+	  all dynamically loaded libraries will appear at random addresses
+	  and therefore be harder to exploit by a technique where an attacker
+	  attempts to execute library code for his purposes (e.g. spawn a
+	  shell from an exploited program that is running at an elevated
+	  privilege level).
+
+	  Furthermore, if a program is relinked as a dynamic ELF file, its
+	  base address will be randomized as well, completing the full
+	  randomization of the address space layout.  Attacking such programs
+	  becomes a guess game.  You can find an example of doing this at
+	  http://pax.grsecurity.net/et_dyn.tar.gz and practical samples at
+	  http://www.grsecurity.net/grsec-gcc-specs.tar.gz .
+
+	  NOTE: you can use the 'chpax' or 'paxctl' utilities to control this
+	  feature on a per file basis.
+
+endmenu
+
+menu "Miscellaneous hardening features"
+
+config PAX_MEMORY_SANITIZE
+	bool "Sanitize all freed memory"
+	help
+	  By saying Y here the kernel will erase memory pages as soon as they
+	  are freed.  This in turn reduces the lifetime of data stored in the
+	  pages, making it less likely that sensitive information such as
+	  passwords, cryptographic secrets, etc stay in memory for too long.
+
+	  This is especially useful for programs whose runtime is short, long
+	  lived processes and the kernel itself benefit from this as long as
+	  they operate on whole memory pages and ensure timely freeing of pages
+	  that may hold sensitive information.
+
+	  The tradeoff is performance impact, on a single CPU system kernel
+	  compilation sees a 3% slowdown, other systems and workloads may vary
+	  and you are advised to test this feature on your expected workload
+	  before deploying it.
+
+	  Note that this feature does not protect data stored in live pages,
+	  e.g., process memory swapped to disk may stay there for a long time.
+
+config PAX_MEMORY_UDEREF
+	bool "Prevent invalid userland pointer dereference"
+	depends on X86_32 && !COMPAT_VDSO
+	help
+	  By saying Y here the kernel will be prevented from dereferencing
+	  userland pointers in contexts where the kernel expects only kernel
+	  pointers.  This is both a useful runtime debugging feature and a
+	  security measure that prevents exploiting a class of kernel bugs.
+
+	  The tradeoff is that some virtualization solutions may experience
+	  a huge slowdown and therefore you should not enable this feature
+	  for kernels meant to run in such environments.  Whether a given VM
+	  solution is affected or not is best determined by simply trying it
+	  out, the performance impact will be obvious right on boot as this
+	  mechanism engages from very early on.  A good rule of thumb is that
+	  VMs running on CPUs without hardware virtualization support (i.e.,
+	  the majority of IA-32 CPUs) will likely experience the slowdown.
+
+endmenu
+
+endmenu
+
+source grsecurity/Kconfig
+
 config KEYS
 	bool "Enable access key retention support"
 	help