Kconfig.hardening 3.4 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788
  1. menu "Kernel hardening options"
  2. menu "Memory initialization"
  3. choice
  4. prompt "Initialize kernel stack variables at function entry"
  5. default INIT_STACK_NONE
  6. help
  7. This option enables initialization of stack variables at
  8. function entry time. This has the possibility to have the
  9. greatest coverage (since all functions can have their
  10. variables initialized), but the performance impact depends
  11. on the function calling complexity of a given workload's
  12. syscalls.
  13. This chooses the level of coverage over classes of potentially
  14. uninitialized variables. The selected class will be
  15. initialized before use in a function.
  16. config INIT_STACK_NONE
  17. bool "no automatic initialization (weakest)"
  18. help
  19. Disable automatic stack variable initialization.
  20. This leaves the kernel vulnerable to the standard
  21. classes of uninitialized stack variable exploits
  22. and information exposures.
  23. config INIT_STACK_ALL_PATTERN
  24. bool "0xAA-init everything on the stack (strongest)"
  25. help
  26. Initializes everything on the stack with a 0xAA
  27. pattern. This is intended to eliminate all classes
  28. of uninitialized stack variable exploits and information
  29. exposures, even variables that were warned to have been
  30. left uninitialized.
  31. Pattern initialization is known to provoke many existing bugs
  32. related to uninitialized locals, e.g. pointers receive
  33. non-NULL values, buffer sizes and indices are very big.
  34. config INIT_STACK_ALL_ZERO
  35. bool "zero-init everything on the stack (strongest and safest)"
  36. help
  37. Initializes everything on the stack with a zero
  38. value. This is intended to eliminate all classes
  39. of uninitialized stack variable exploits and information
  40. exposures, even variables that were warned to have been
  41. left uninitialized.
  42. Zero initialization provides safe defaults for strings,
  43. pointers, indices and sizes, and is therefore
  44. more suitable as a security mitigation measure.
  45. endchoice
  46. config INIT_ON_ALLOC_DEFAULT_ON
  47. bool "Enable heap memory zeroing on allocation by default"
  48. help
  49. This has the effect of setting "init_on_alloc=1" on the kernel
  50. command line. This can be disabled with "init_on_alloc=0".
  51. When "init_on_alloc" is enabled, all page allocator and slab
  52. allocator memory will be zeroed when allocated, eliminating
  53. many kinds of "uninitialized heap memory" flaws, especially
  54. heap content exposures. The performance impact varies by
  55. workload, but most cases see <1% impact. Some synthetic
  56. workloads have measured as high as 7%.
  57. config INIT_ON_FREE_DEFAULT_ON
  58. bool "Enable heap memory zeroing on free by default"
  59. help
  60. This has the effect of setting "init_on_free=1" on the kernel
  61. command line. This can be disabled with "init_on_free=0".
  62. Similar to "init_on_alloc", when "init_on_free" is enabled,
  63. all page allocator and slab allocator memory will be zeroed
  64. when freed, eliminating many kinds of "uninitialized heap memory"
  65. flaws, especially heap content exposures. The primary difference
  66. with "init_on_free" is that data lifetime in memory is reduced,
  67. as anything freed is wiped immediately, making live forensics or
  68. cold boot memory attacks unable to recover freed memory contents.
  69. The performance impact varies by workload, but is more expensive
  70. than "init_on_alloc" due to the negative cache effects of
  71. touching "cold" memory areas. Most cases see 3-5% impact. Some
  72. synthetic workloads have measured as high as 8%.
  73. endmenu
  74. endmenu