1# SPDX-License-Identifier: GPL-2.0-only 2config 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 11config 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 41config 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 48config 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 59config 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 73config PAGE_OWNER 74 bool "Track page owner" 75 depends on DEBUG_KERNEL && STACKTRACE_SUPPORT 76 select DEBUG_FS 77 select STACKTRACE 78 select STACKDEPOT 79 select PAGE_EXTENSION 80 help 81 This keeps track of what call chain is the owner of a page, may 82 help to find bare alloc_page(s) leaks. Even if you include this 83 feature on your build, it is disabled in default. You should pass 84 "page_owner=on" to boot parameter in order to enable it. Eats 85 a fair amount of memory if enabled. See tools/mm/page_owner_sort.c 86 for user-space helper. 87 88 If unsure, say N. 89 90config PAGE_TABLE_CHECK 91 bool "Check for invalid mappings in user page tables" 92 depends on ARCH_SUPPORTS_PAGE_TABLE_CHECK 93 depends on EXCLUSIVE_SYSTEM_RAM 94 select PAGE_EXTENSION 95 help 96 Check that anonymous page is not being mapped twice with read write 97 permissions. Check that anonymous and file pages are not being 98 erroneously shared. Since the checking is performed at the time 99 entries are added and removed to user page tables, leaking, corruption 100 and double mapping problems are detected synchronously. 101 102 If unsure say "n". 103 104config PAGE_TABLE_CHECK_ENFORCED 105 bool "Enforce the page table checking by default" 106 depends on PAGE_TABLE_CHECK 107 help 108 Always enable page table checking. By default the page table checking 109 is disabled, and can be optionally enabled via page_table_check=on 110 kernel parameter. This config enforces that page table check is always 111 enabled. 112 113 If unsure say "n". 114 115config PAGE_POISONING 116 bool "Poison pages after freeing" 117 help 118 Fill the pages with poison patterns after free_pages() and verify 119 the patterns before alloc_pages. The filling of the memory helps 120 reduce the risk of information leaks from freed data. This does 121 have a potential performance impact if enabled with the 122 "page_poison=1" kernel boot option. 123 124 Note that "poison" here is not the same thing as the "HWPoison" 125 for CONFIG_MEMORY_FAILURE. This is software poisoning only. 126 127 If you are only interested in sanitization of freed pages without 128 checking the poison pattern on alloc, you can boot the kernel with 129 "init_on_free=1" instead of enabling this. 130 131 If unsure, say N 132 133config DEBUG_PAGE_REF 134 bool "Enable tracepoint to track down page reference manipulation" 135 depends on DEBUG_KERNEL 136 depends on TRACEPOINTS 137 help 138 This is a feature to add tracepoint for tracking down page reference 139 manipulation. This tracking is useful to diagnose functional failure 140 due to migration failures caused by page reference mismatches. Be 141 careful when enabling this feature because it adds about 30 KB to the 142 kernel code. However the runtime performance overhead is virtually 143 nil until the tracepoints are actually enabled. 144 145config DEBUG_RODATA_TEST 146 bool "Testcase for the marking rodata read-only" 147 depends on STRICT_KERNEL_RWX 148 help 149 This option enables a testcase for the setting rodata read-only. 150 151config ARCH_HAS_DEBUG_WX 152 bool 153 154config DEBUG_WX 155 bool "Warn on W+X mappings at boot" 156 depends on ARCH_HAS_DEBUG_WX 157 depends on MMU 158 select PTDUMP_CORE 159 help 160 Generate a warning if any W+X mappings are found at boot. 161 162 This is useful for discovering cases where the kernel is leaving W+X 163 mappings after applying NX, as such mappings are a security risk. 164 165 Look for a message in dmesg output like this: 166 167 <arch>/mm: Checked W+X mappings: passed, no W+X pages found. 168 169 or like this, if the check failed: 170 171 <arch>/mm: Checked W+X mappings: failed, <N> W+X pages found. 172 173 Note that even if the check fails, your kernel is possibly 174 still fine, as W+X mappings are not a security hole in 175 themselves, what they do is that they make the exploitation 176 of other unfixed kernel bugs easier. 177 178 There is no runtime or memory usage effect of this option 179 once the kernel has booted up - it's a one time check. 180 181 If in doubt, say "Y". 182 183config GENERIC_PTDUMP 184 bool 185 186config PTDUMP_CORE 187 bool 188 189config PTDUMP_DEBUGFS 190 bool "Export kernel pagetable layout to userspace via debugfs" 191 depends on DEBUG_KERNEL 192 depends on DEBUG_FS 193 depends on GENERIC_PTDUMP 194 select PTDUMP_CORE 195 help 196 Say Y here if you want to show the kernel pagetable layout in a 197 debugfs file. This information is only useful for kernel developers 198 who are working in architecture specific areas of the kernel. 199 It is probably not a good idea to enable this feature in a production 200 kernel. 201 202 If in doubt, say N. 203 204config HAVE_DEBUG_KMEMLEAK 205 bool 206 207config DEBUG_KMEMLEAK 208 bool "Kernel memory leak detector" 209 depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK 210 select DEBUG_FS 211 select STACKTRACE if STACKTRACE_SUPPORT 212 select KALLSYMS 213 select CRC32 214 select STACKDEPOT 215 select STACKDEPOT_ALWAYS_INIT if !DEBUG_KMEMLEAK_DEFAULT_OFF 216 help 217 Say Y here if you want to enable the memory leak 218 detector. The memory allocation/freeing is traced in a way 219 similar to the Boehm's conservative garbage collector, the 220 difference being that the orphan objects are not freed but 221 only shown in /sys/kernel/debug/kmemleak. Enabling this 222 feature will introduce an overhead to memory 223 allocations. See Documentation/dev-tools/kmemleak.rst for more 224 details. 225 226 Enabling SLUB_DEBUG may increase the chances of finding leaks 227 due to the slab objects poisoning. 228 229 In order to access the kmemleak file, debugfs needs to be 230 mounted (usually at /sys/kernel/debug). 231 232config DEBUG_KMEMLEAK_MEM_POOL_SIZE 233 int "Kmemleak memory pool size" 234 depends on DEBUG_KMEMLEAK 235 range 200 1000000 236 default 16000 237 help 238 Kmemleak must track all the memory allocations to avoid 239 reporting false positives. Since memory may be allocated or 240 freed before kmemleak is fully initialised, use a static pool 241 of metadata objects to track such callbacks. After kmemleak is 242 fully initialised, this memory pool acts as an emergency one 243 if slab allocations fail. 244 245config DEBUG_KMEMLEAK_DEFAULT_OFF 246 bool "Default kmemleak to off" 247 depends on DEBUG_KMEMLEAK 248 help 249 Say Y here to disable kmemleak by default. It can then be enabled 250 on the command line via kmemleak=on. 251 252config DEBUG_KMEMLEAK_AUTO_SCAN 253 bool "Enable kmemleak auto scan thread on boot up" 254 default y 255 depends on DEBUG_KMEMLEAK 256 help 257 Depending on the cpu, kmemleak scan may be cpu intensive and can 258 stall user tasks at times. This option enables/disables automatic 259 kmemleak scan at boot up. 260 261 Say N here to disable kmemleak auto scan thread to stop automatic 262 scanning. Disabling this option disables automatic reporting of 263 memory leaks. 264 265 If unsure, say Y. 266 267config PER_VMA_LOCK_STATS 268 bool "Statistics for per-vma locks" 269 depends on PER_VMA_LOCK 270 help 271 Say Y here to enable success, retry and failure counters of page 272 faults handled under protection of per-vma locks. When enabled, the 273 counters are exposed in /proc/vmstat. This information is useful for 274 kernel developers to evaluate effectiveness of per-vma locks and to 275 identify pathological cases. Counting these events introduces a small 276 overhead in the page fault path. 277 278 If in doubt, say N. 279