| 1 | # SPDX-License-Identifier: GPL-2.0-only |
| 2 | config PAGE_EXTENSION |
| 3 | bool "Extend memmap on extra space for more information on page" |
| 4 | help |
| 5 | Extend memmap on extra space for more information on page. This |
| 6 | could be used for debugging features that need to insert extra |
| 7 | field for every page. This extension enables us to save memory |
| 8 | by not allocating this extra memory according to boottime |
| 9 | configuration. |
| 10 | |
| 11 | config DEBUG_PAGEALLOC |
| 12 | bool "Debug page memory allocations" |
| 13 | depends on DEBUG_KERNEL |
| 14 | depends on !HIBERNATION || ARCH_SUPPORTS_DEBUG_PAGEALLOC && !PPC && !SPARC |
| 15 | select PAGE_POISONING if !ARCH_SUPPORTS_DEBUG_PAGEALLOC |
| 16 | help |
| 17 | Unmap pages from the kernel linear mapping after free_pages(). |
| 18 | Depending on runtime enablement, this results in a small or large |
| 19 | slowdown, but helps to find certain types of memory corruption. |
| 20 | |
| 21 | Also, the state of page tracking structures is checked more often as |
| 22 | pages are being allocated and freed, as unexpected state changes |
| 23 | often happen for same reasons as memory corruption (e.g. double free, |
| 24 | use-after-free). The error reports for these checks can be augmented |
| 25 | with stack traces of last allocation and freeing of the page, when |
| 26 | PAGE_OWNER is also selected and enabled on boot. |
| 27 | |
| 28 | For architectures which don't enable ARCH_SUPPORTS_DEBUG_PAGEALLOC, |
| 29 | fill the pages with poison patterns after free_pages() and verify |
| 30 | the patterns before alloc_pages(). Additionally, this option cannot |
| 31 | be enabled in combination with hibernation as that would result in |
| 32 | incorrect warnings of memory corruption after a resume because free |
| 33 | pages are not saved to the suspend image. |
| 34 | |
| 35 | By default this option will have a small overhead, e.g. by not |
| 36 | allowing the kernel mapping to be backed by large pages on some |
| 37 | architectures. Even bigger overhead comes when the debugging is |
| 38 | enabled by DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc |
| 39 | command line parameter. |
| 40 | |
| 41 | config DEBUG_PAGEALLOC_ENABLE_DEFAULT |
| 42 | bool "Enable debug page memory allocations by default?" |
| 43 | depends on DEBUG_PAGEALLOC |
| 44 | help |
| 45 | Enable debug page memory allocations by default? This value |
| 46 | can be overridden by debug_pagealloc=off|on. |
| 47 | |
| 48 | config SLUB_DEBUG |
| 49 | default y |
| 50 | bool "Enable SLUB debugging support" if EXPERT |
| 51 | depends on SYSFS && !SLUB_TINY |
| 52 | select STACKDEPOT if STACKTRACE_SUPPORT |
| 53 | help |
| 54 | SLUB has extensive debug support features. Disabling these can |
| 55 | result in significant savings in code size. While /sys/kernel/slab |
| 56 | will still exist (with SYSFS enabled), it will not provide e.g. cache |
| 57 | validation. |
| 58 | |
| 59 | config SLUB_DEBUG_ON |
| 60 | bool "SLUB debugging on by default" |
| 61 | depends on SLUB_DEBUG |
| 62 | select STACKDEPOT_ALWAYS_INIT if STACKTRACE_SUPPORT |
| 63 | default n |
| 64 | help |
| 65 | Boot with debugging on by default. SLUB boots by default with |
| 66 | the runtime debug capabilities switched off. Enabling this is |
| 67 | equivalent to specifying the "slab_debug" parameter on boot. |
| 68 | There is no support for more fine grained debug control like |
| 69 | possible with slab_debug=xxx. SLUB debugging may be switched |
| 70 | off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying |
| 71 | "slab_debug=-". |
| 72 | |
| 73 | config SLUB_RCU_DEBUG |
| 74 | bool "Enable UAF detection in TYPESAFE_BY_RCU caches (for KASAN)" |
| 75 | depends on SLUB_DEBUG |
| 76 | # SLUB_RCU_DEBUG should build fine without KASAN, but is currently useless |
| 77 | # without KASAN, so mark it as a dependency of KASAN for now. |
| 78 | depends on KASAN |
| 79 | default KASAN_GENERIC || KASAN_SW_TAGS |
| 80 | help |
| 81 | Make SLAB_TYPESAFE_BY_RCU caches behave approximately as if the cache |
| 82 | was not marked as SLAB_TYPESAFE_BY_RCU and every caller used |
| 83 | kfree_rcu() instead. |
| 84 | |
| 85 | This is intended for use in combination with KASAN, to enable KASAN to |
| 86 | detect use-after-free accesses in such caches. |
| 87 | (KFENCE is able to do that independent of this flag.) |
| 88 | |
| 89 | This might degrade performance. |
| 90 | Unfortunately this also prevents a very specific bug pattern from |
| 91 | triggering (insufficient checks against an object being recycled |
| 92 | within the RCU grace period); so this option can be turned off even on |
| 93 | KASAN builds, in case you want to test for such a bug. |
| 94 | |
| 95 | If you're using this for testing bugs / fuzzing and care about |
| 96 | catching all the bugs WAY more than performance, you might want to |
| 97 | also turn on CONFIG_RCU_STRICT_GRACE_PERIOD. |
| 98 | |
| 99 | WARNING: |
| 100 | This is designed as a debugging feature, not a security feature. |
| 101 | Objects are sometimes recycled without RCU delay under memory pressure. |
| 102 | |
| 103 | If unsure, say N. |
| 104 | |
| 105 | config PAGE_OWNER |
| 106 | bool "Track page owner" |
| 107 | depends on DEBUG_KERNEL && STACKTRACE_SUPPORT |
| 108 | select DEBUG_FS |
| 109 | select STACKTRACE |
| 110 | select STACKDEPOT |
| 111 | select PAGE_EXTENSION |
| 112 | help |
| 113 | This keeps track of what call chain is the owner of a page, may |
| 114 | help to find bare alloc_page(s) leaks. Even if you include this |
| 115 | feature on your build, it is disabled in default. You should pass |
| 116 | "page_owner=on" to boot parameter in order to enable it. Eats |
| 117 | a fair amount of memory if enabled. See tools/mm/page_owner_sort.c |
| 118 | for user-space helper. |
| 119 | |
| 120 | If unsure, say N. |
| 121 | |
| 122 | config PAGE_TABLE_CHECK |
| 123 | bool "Check for invalid mappings in user page tables" |
| 124 | depends on ARCH_SUPPORTS_PAGE_TABLE_CHECK |
| 125 | depends on EXCLUSIVE_SYSTEM_RAM |
| 126 | select PAGE_EXTENSION |
| 127 | help |
| 128 | Check that anonymous page is not being mapped twice with read write |
| 129 | permissions. Check that anonymous and file pages are not being |
| 130 | erroneously shared. Since the checking is performed at the time |
| 131 | entries are added and removed to user page tables, leaking, corruption |
| 132 | and double mapping problems are detected synchronously. |
| 133 | |
| 134 | If unsure say "n". |
| 135 | |
| 136 | config PAGE_TABLE_CHECK_ENFORCED |
| 137 | bool "Enforce the page table checking by default" |
| 138 | depends on PAGE_TABLE_CHECK |
| 139 | help |
| 140 | Always enable page table checking. By default the page table checking |
| 141 | is disabled, and can be optionally enabled via page_table_check=on |
| 142 | kernel parameter. This config enforces that page table check is always |
| 143 | enabled. |
| 144 | |
| 145 | If unsure say "n". |
| 146 | |
| 147 | config PAGE_POISONING |
| 148 | bool "Poison pages after freeing" |
| 149 | help |
| 150 | Fill the pages with poison patterns after free_pages() and verify |
| 151 | the patterns before alloc_pages. The filling of the memory helps |
| 152 | reduce the risk of information leaks from freed data. This does |
| 153 | have a potential performance impact if enabled with the |
| 154 | "page_poison=1" kernel boot option. |
| 155 | |
| 156 | Note that "poison" here is not the same thing as the "HWPoison" |
| 157 | for CONFIG_MEMORY_FAILURE. This is software poisoning only. |
| 158 | |
| 159 | If you are only interested in sanitization of freed pages without |
| 160 | checking the poison pattern on alloc, you can boot the kernel with |
| 161 | "init_on_free=1" instead of enabling this. |
| 162 | |
| 163 | If unsure, say N |
| 164 | |
| 165 | config DEBUG_PAGE_REF |
| 166 | bool "Enable tracepoint to track down page reference manipulation" |
| 167 | depends on DEBUG_KERNEL |
| 168 | depends on TRACEPOINTS |
| 169 | help |
| 170 | This is a feature to add tracepoint for tracking down page reference |
| 171 | manipulation. This tracking is useful to diagnose functional failure |
| 172 | due to migration failures caused by page reference mismatches. Be |
| 173 | careful when enabling this feature because it adds about 30 KB to the |
| 174 | kernel code. However the runtime performance overhead is virtually |
| 175 | nil until the tracepoints are actually enabled. |
| 176 | |
| 177 | config DEBUG_RODATA_TEST |
| 178 | bool "Testcase for the marking rodata read-only" |
| 179 | depends on STRICT_KERNEL_RWX |
| 180 | help |
| 181 | This option enables a testcase for the setting rodata read-only. |
| 182 | |
| 183 | config ARCH_HAS_DEBUG_WX |
| 184 | bool |
| 185 | |
| 186 | config DEBUG_WX |
| 187 | bool "Warn on W+X mappings at boot" |
| 188 | depends on ARCH_HAS_DEBUG_WX |
| 189 | depends on ARCH_HAS_PTDUMP |
| 190 | depends on MMU |
| 191 | select PTDUMP |
| 192 | help |
| 193 | Generate a warning if any W+X mappings are found at boot. |
| 194 | |
| 195 | This is useful for discovering cases where the kernel is leaving W+X |
| 196 | mappings after applying NX, as such mappings are a security risk. |
| 197 | |
| 198 | Look for a message in dmesg output like this: |
| 199 | |
| 200 | <arch>/mm: Checked W+X mappings: passed, no W+X pages found. |
| 201 | |
| 202 | or like this, if the check failed: |
| 203 | |
| 204 | <arch>/mm: Checked W+X mappings: failed, <N> W+X pages found. |
| 205 | |
| 206 | Note that even if the check fails, your kernel is possibly |
| 207 | still fine, as W+X mappings are not a security hole in |
| 208 | themselves, what they do is that they make the exploitation |
| 209 | of other unfixed kernel bugs easier. |
| 210 | |
| 211 | There is no runtime or memory usage effect of this option |
| 212 | once the kernel has booted up - it's a one time check. |
| 213 | |
| 214 | If in doubt, say "Y". |
| 215 | |
| 216 | config ARCH_HAS_PTDUMP |
| 217 | bool |
| 218 | |
| 219 | config PTDUMP |
| 220 | bool |
| 221 | |
| 222 | config PTDUMP_DEBUGFS |
| 223 | bool "Export kernel pagetable layout to userspace via debugfs" |
| 224 | depends on DEBUG_KERNEL |
| 225 | depends on DEBUG_FS |
| 226 | depends on ARCH_HAS_PTDUMP |
| 227 | select PTDUMP |
| 228 | help |
| 229 | Say Y here if you want to show the kernel pagetable layout in a |
| 230 | debugfs file. This information is only useful for kernel developers |
| 231 | who are working in architecture specific areas of the kernel. |
| 232 | It is probably not a good idea to enable this feature in a production |
| 233 | kernel. |
| 234 | |
| 235 | If in doubt, say N. |
| 236 | |
| 237 | config HAVE_DEBUG_KMEMLEAK |
| 238 | bool |
| 239 | |
| 240 | config DEBUG_KMEMLEAK |
| 241 | bool "Kernel memory leak detector" |
| 242 | depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK |
| 243 | select DEBUG_FS |
| 244 | select STACKTRACE if STACKTRACE_SUPPORT |
| 245 | select KALLSYMS |
| 246 | select CRC32 |
| 247 | select STACKDEPOT |
| 248 | select STACKDEPOT_ALWAYS_INIT if !DEBUG_KMEMLEAK_DEFAULT_OFF |
| 249 | help |
| 250 | Say Y here if you want to enable the memory leak |
| 251 | detector. The memory allocation/freeing is traced in a way |
| 252 | similar to the Boehm's conservative garbage collector, the |
| 253 | difference being that the orphan objects are not freed but |
| 254 | only shown in /sys/kernel/debug/kmemleak. Enabling this |
| 255 | feature will introduce an overhead to memory |
| 256 | allocations. See Documentation/dev-tools/kmemleak.rst for more |
| 257 | details. |
| 258 | |
| 259 | Enabling SLUB_DEBUG may increase the chances of finding leaks |
| 260 | due to the slab objects poisoning. |
| 261 | |
| 262 | In order to access the kmemleak file, debugfs needs to be |
| 263 | mounted (usually at /sys/kernel/debug). |
| 264 | |
| 265 | config DEBUG_KMEMLEAK_MEM_POOL_SIZE |
| 266 | int "Kmemleak memory pool size" |
| 267 | depends on DEBUG_KMEMLEAK |
| 268 | range 200 1000000 |
| 269 | default 16000 |
| 270 | help |
| 271 | Kmemleak must track all the memory allocations to avoid |
| 272 | reporting false positives. Since memory may be allocated or |
| 273 | freed before kmemleak is fully initialised, use a static pool |
| 274 | of metadata objects to track such callbacks. After kmemleak is |
| 275 | fully initialised, this memory pool acts as an emergency one |
| 276 | if slab allocations fail. |
| 277 | |
| 278 | config DEBUG_KMEMLEAK_DEFAULT_OFF |
| 279 | bool "Default kmemleak to off" |
| 280 | depends on DEBUG_KMEMLEAK |
| 281 | help |
| 282 | Say Y here to disable kmemleak by default. It can then be enabled |
| 283 | on the command line via kmemleak=on. |
| 284 | |
| 285 | config DEBUG_KMEMLEAK_AUTO_SCAN |
| 286 | bool "Enable kmemleak auto scan thread on boot up" |
| 287 | default y |
| 288 | depends on DEBUG_KMEMLEAK |
| 289 | help |
| 290 | Depending on the cpu, kmemleak scan may be cpu intensive and can |
| 291 | stall user tasks at times. This option enables/disables automatic |
| 292 | kmemleak scan at boot up. |
| 293 | |
| 294 | Say N here to disable kmemleak auto scan thread to stop automatic |
| 295 | scanning. Disabling this option disables automatic reporting of |
| 296 | memory leaks. |
| 297 | |
| 298 | If unsure, say Y. |
| 299 | |
| 300 | config DEBUG_KMEMLEAK_VERBOSE |
| 301 | bool "Default kmemleak to verbose mode" |
| 302 | depends on DEBUG_KMEMLEAK_AUTO_SCAN |
| 303 | help |
| 304 | Say Y here to have kmemleak print unreferenced object details |
| 305 | (backtrace, hex dump, address) to dmesg when new memory leaks are |
| 306 | detected during automatic scanning. This can also be toggled at |
| 307 | runtime via /sys/module/kmemleak/parameters/verbose. |
| 308 | |
| 309 | If unsure, say N. |
| 310 | |
| 311 | config PER_VMA_LOCK_STATS |
| 312 | bool "Statistics for per-vma locks" |
| 313 | depends on PER_VMA_LOCK |
| 314 | help |
| 315 | Say Y here to enable success, retry and failure counters of page |
| 316 | faults handled under protection of per-vma locks. When enabled, the |
| 317 | counters are exposed in /proc/vmstat. This information is useful for |
| 318 | kernel developers to evaluate effectiveness of per-vma locks and to |
| 319 | identify pathological cases. Counting these events introduces a small |
| 320 | overhead in the page fault path. |
| 321 | |
| 322 | If in doubt, say N. |
| 323 | |
| 324 | config MEM_ALLOC_PROFILING |
| 325 | bool "Enable memory allocation profiling" |
| 326 | default n |
| 327 | depends on MMU |
| 328 | depends on PROC_FS |
| 329 | select CODE_TAGGING |
| 330 | select PAGE_EXTENSION |
| 331 | select SLAB_OBJ_EXT |
| 332 | help |
| 333 | Track allocation source code and record total allocation size |
| 334 | initiated at that code location. The mechanism can be used to track |
| 335 | memory leaks with a low performance and memory impact. |
| 336 | |
| 337 | config MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT |
| 338 | bool "Enable memory allocation profiling by default" |
| 339 | default y |
| 340 | depends on MEM_ALLOC_PROFILING |
| 341 | |
| 342 | config MEM_ALLOC_PROFILING_DEBUG |
| 343 | bool "Memory allocation profiler debugging" |
| 344 | default n |
| 345 | depends on MEM_ALLOC_PROFILING |
| 346 | select MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT |
| 347 | help |
| 348 | Adds warnings with helpful error messages for memory allocation |
| 349 | profiling. |