Kconfig.hardening 8.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222
  1. # SPDX-License-Identifier: GPL-2.0-only
  2. menu "Kernel hardening options"
  3. config GCC_PLUGIN_STRUCTLEAK
  4. bool
  5. help
  6. While the kernel is built with warnings enabled for any missed
  7. stack variable initializations, this warning is silenced for
  8. anything passed by reference to another function, under the
  9. occasionally misguided assumption that the function will do
  10. the initialization. As this regularly leads to exploitable
  11. flaws, this plugin is available to identify and zero-initialize
  12. such variables, depending on the chosen level of coverage.
  13. This plugin was originally ported from grsecurity/PaX. More
  14. information at:
  15. * https://grsecurity.net/
  16. * https://pax.grsecurity.net/
  17. menu "Memory initialization"
  18. config CC_HAS_AUTO_VAR_INIT_PATTERN
  19. def_bool $(cc-option,-ftrivial-auto-var-init=pattern)
  20. config CC_HAS_AUTO_VAR_INIT_ZERO
  21. def_bool $(cc-option,-ftrivial-auto-var-init=zero -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang)
  22. choice
  23. prompt "Initialize kernel stack variables at function entry"
  24. default GCC_PLUGIN_STRUCTLEAK_BYREF_ALL if COMPILE_TEST && GCC_PLUGINS
  25. default INIT_STACK_ALL_PATTERN if COMPILE_TEST && CC_HAS_AUTO_VAR_INIT_PATTERN
  26. default INIT_STACK_NONE
  27. help
  28. This option enables initialization of stack variables at
  29. function entry time. This has the possibility to have the
  30. greatest coverage (since all functions can have their
  31. variables initialized), but the performance impact depends
  32. on the function calling complexity of a given workload's
  33. syscalls.
  34. This chooses the level of coverage over classes of potentially
  35. uninitialized variables. The selected class will be
  36. initialized before use in a function.
  37. config INIT_STACK_NONE
  38. bool "no automatic initialization (weakest)"
  39. help
  40. Disable automatic stack variable initialization.
  41. This leaves the kernel vulnerable to the standard
  42. classes of uninitialized stack variable exploits
  43. and information exposures.
  44. config GCC_PLUGIN_STRUCTLEAK_USER
  45. bool "zero-init structs marked for userspace (weak)"
  46. depends on GCC_PLUGINS
  47. select GCC_PLUGIN_STRUCTLEAK
  48. help
  49. Zero-initialize any structures on the stack containing
  50. a __user attribute. This can prevent some classes of
  51. uninitialized stack variable exploits and information
  52. exposures, like CVE-2013-2141:
  53. https://git.kernel.org/linus/b9e146d8eb3b9eca
  54. config GCC_PLUGIN_STRUCTLEAK_BYREF
  55. bool "zero-init structs passed by reference (strong)"
  56. depends on GCC_PLUGINS
  57. depends on !(KASAN && KASAN_STACK)
  58. select GCC_PLUGIN_STRUCTLEAK
  59. help
  60. Zero-initialize any structures on the stack that may
  61. be passed by reference and had not already been
  62. explicitly initialized. This can prevent most classes
  63. of uninitialized stack variable exploits and information
  64. exposures, like CVE-2017-1000410:
  65. https://git.kernel.org/linus/06e7e776ca4d3654
  66. As a side-effect, this keeps a lot of variables on the
  67. stack that can otherwise be optimized out, so combining
  68. this with CONFIG_KASAN_STACK can lead to a stack overflow
  69. and is disallowed.
  70. config GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
  71. bool "zero-init anything passed by reference (very strong)"
  72. depends on GCC_PLUGINS
  73. depends on !(KASAN && KASAN_STACK)
  74. select GCC_PLUGIN_STRUCTLEAK
  75. help
  76. Zero-initialize any stack variables that may be passed
  77. by reference and had not already been explicitly
  78. initialized. This is intended to eliminate all classes
  79. of uninitialized stack variable exploits and information
  80. exposures.
  81. config INIT_STACK_ALL_PATTERN
  82. bool "0xAA-init everything on the stack (strongest)"
  83. depends on CC_HAS_AUTO_VAR_INIT_PATTERN
  84. help
  85. Initializes everything on the stack with a 0xAA
  86. pattern. This is intended to eliminate all classes
  87. of uninitialized stack variable exploits and information
  88. exposures, even variables that were warned to have been
  89. left uninitialized.
  90. Pattern initialization is known to provoke many existing bugs
  91. related to uninitialized locals, e.g. pointers receive
  92. non-NULL values, buffer sizes and indices are very big.
  93. config INIT_STACK_ALL_ZERO
  94. bool "zero-init everything on the stack (strongest and safest)"
  95. depends on CC_HAS_AUTO_VAR_INIT_ZERO
  96. help
  97. Initializes everything on the stack with a zero
  98. value. This is intended to eliminate all classes
  99. of uninitialized stack variable exploits and information
  100. exposures, even variables that were warned to have been
  101. left uninitialized.
  102. Zero initialization provides safe defaults for strings,
  103. pointers, indices and sizes, and is therefore
  104. more suitable as a security mitigation measure.
  105. endchoice
  106. config GCC_PLUGIN_STRUCTLEAK_VERBOSE
  107. bool "Report forcefully initialized variables"
  108. depends on GCC_PLUGIN_STRUCTLEAK
  109. depends on !COMPILE_TEST # too noisy
  110. help
  111. This option will cause a warning to be printed each time the
  112. structleak plugin finds a variable it thinks needs to be
  113. initialized. Since not all existing initializers are detected
  114. by the plugin, this can produce false positive warnings.
  115. config GCC_PLUGIN_STACKLEAK
  116. bool "Poison kernel stack before returning from syscalls"
  117. depends on GCC_PLUGINS
  118. depends on HAVE_ARCH_STACKLEAK
  119. help
  120. This option makes the kernel erase the kernel stack before
  121. returning from system calls. This has the effect of leaving
  122. the stack initialized to the poison value, which both reduces
  123. the lifetime of any sensitive stack contents and reduces
  124. potential for uninitialized stack variable exploits or information
  125. exposures (it does not cover functions reaching the same stack
  126. depth as prior functions during the same syscall). This blocks
  127. most uninitialized stack variable attacks, with the performance
  128. impact being driven by the depth of the stack usage, rather than
  129. the function calling complexity.
  130. The performance impact on a single CPU system kernel compilation
  131. sees a 1% slowdown, other systems and workloads may vary and you
  132. are advised to test this feature on your expected workload before
  133. deploying it.
  134. This plugin was ported from grsecurity/PaX. More information at:
  135. * https://grsecurity.net/
  136. * https://pax.grsecurity.net/
  137. config STACKLEAK_TRACK_MIN_SIZE
  138. int "Minimum stack frame size of functions tracked by STACKLEAK"
  139. default 100
  140. range 0 4096
  141. depends on GCC_PLUGIN_STACKLEAK
  142. help
  143. The STACKLEAK gcc plugin instruments the kernel code for tracking
  144. the lowest border of the kernel stack (and for some other purposes).
  145. It inserts the stackleak_track_stack() call for the functions with
  146. a stack frame size greater than or equal to this parameter.
  147. If unsure, leave the default value 100.
  148. config STACKLEAK_METRICS
  149. bool "Show STACKLEAK metrics in the /proc file system"
  150. depends on GCC_PLUGIN_STACKLEAK
  151. depends on PROC_FS
  152. help
  153. If this is set, STACKLEAK metrics for every task are available in
  154. the /proc file system. In particular, /proc/<pid>/stack_depth
  155. shows the maximum kernel stack consumption for the current and
  156. previous syscalls. Although this information is not precise, it
  157. can be useful for estimating the STACKLEAK performance impact for
  158. your workloads.
  159. config STACKLEAK_RUNTIME_DISABLE
  160. bool "Allow runtime disabling of kernel stack erasing"
  161. depends on GCC_PLUGIN_STACKLEAK
  162. help
  163. This option provides 'stack_erasing' sysctl, which can be used in
  164. runtime to control kernel stack erasing for kernels built with
  165. CONFIG_GCC_PLUGIN_STACKLEAK.
  166. config INIT_ON_ALLOC_DEFAULT_ON
  167. bool "Enable heap memory zeroing on allocation by default"
  168. help
  169. This has the effect of setting "init_on_alloc=1" on the kernel
  170. command line. This can be disabled with "init_on_alloc=0".
  171. When "init_on_alloc" is enabled, all page allocator and slab
  172. allocator memory will be zeroed when allocated, eliminating
  173. many kinds of "uninitialized heap memory" flaws, especially
  174. heap content exposures. The performance impact varies by
  175. workload, but most cases see <1% impact. Some synthetic
  176. workloads have measured as high as 7%.
  177. config INIT_ON_FREE_DEFAULT_ON
  178. bool "Enable heap memory zeroing on free by default"
  179. help
  180. This has the effect of setting "init_on_free=1" on the kernel
  181. command line. This can be disabled with "init_on_free=0".
  182. Similar to "init_on_alloc", when "init_on_free" is enabled,
  183. all page allocator and slab allocator memory will be zeroed
  184. when freed, eliminating many kinds of "uninitialized heap memory"
  185. flaws, especially heap content exposures. The primary difference
  186. with "init_on_free" is that data lifetime in memory is reduced,
  187. as anything freed is wiped immediately, making live forensics or
  188. cold boot memory attacks unable to recover freed memory contents.
  189. The performance impact varies by workload, but is more expensive
  190. than "init_on_alloc" due to the negative cache effects of
  191. touching "cold" memory areas. Most cases see 3-5% impact. Some
  192. synthetic workloads have measured as high as 8%.
  193. endmenu
  194. endmenu