| # SPDX-License-Identifier: GPL-2.0-only | 
 | config PAGE_EXTENSION | 
 | 	bool "Extend memmap on extra space for more information on page" | 
 | 	help | 
 | 	  Extend memmap on extra space for more information on page. This | 
 | 	  could be used for debugging features that need to insert extra | 
 | 	  field for every page. This extension enables us to save memory | 
 | 	  by not allocating this extra memory according to boottime | 
 | 	  configuration. | 
 |  | 
 | config DEBUG_PAGEALLOC | 
 | 	bool "Debug page memory allocations" | 
 | 	depends on DEBUG_KERNEL | 
 | 	depends on !HIBERNATION || ARCH_SUPPORTS_DEBUG_PAGEALLOC && !PPC && !SPARC | 
 | 	select PAGE_POISONING if !ARCH_SUPPORTS_DEBUG_PAGEALLOC | 
 | 	help | 
 | 	  Unmap pages from the kernel linear mapping after free_pages(). | 
 | 	  Depending on runtime enablement, this results in a small or large | 
 | 	  slowdown, but helps to find certain types of memory corruption. | 
 |  | 
 | 	  Also, the state of page tracking structures is checked more often as | 
 | 	  pages are being allocated and freed, as unexpected state changes | 
 | 	  often happen for same reasons as memory corruption (e.g. double free, | 
 | 	  use-after-free). The error reports for these checks can be augmented | 
 | 	  with stack traces of last allocation and freeing of the page, when | 
 | 	  PAGE_OWNER is also selected and enabled on boot. | 
 |  | 
 | 	  For architectures which don't enable ARCH_SUPPORTS_DEBUG_PAGEALLOC, | 
 | 	  fill the pages with poison patterns after free_pages() and verify | 
 | 	  the patterns before alloc_pages(). Additionally, this option cannot | 
 | 	  be enabled in combination with hibernation as that would result in | 
 | 	  incorrect warnings of memory corruption after a resume because free | 
 | 	  pages are not saved to the suspend image. | 
 |  | 
 | 	  By default this option will have a small overhead, e.g. by not | 
 | 	  allowing the kernel mapping to be backed by large pages on some | 
 | 	  architectures. Even bigger overhead comes when the debugging is | 
 | 	  enabled by DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc | 
 | 	  command line parameter. | 
 |  | 
 | config DEBUG_PAGEALLOC_ENABLE_DEFAULT | 
 | 	bool "Enable debug page memory allocations by default?" | 
 | 	depends on DEBUG_PAGEALLOC | 
 | 	help | 
 | 	  Enable debug page memory allocations by default? This value | 
 | 	  can be overridden by debug_pagealloc=off|on. | 
 |  | 
 | config SLUB_DEBUG | 
 | 	default y | 
 | 	bool "Enable SLUB debugging support" if EXPERT | 
 | 	depends on SYSFS && !SLUB_TINY | 
 | 	select STACKDEPOT if STACKTRACE_SUPPORT | 
 | 	help | 
 | 	  SLUB has extensive debug support features. Disabling these can | 
 | 	  result in significant savings in code size. While /sys/kernel/slab | 
 | 	  will still exist (with SYSFS enabled), it will not provide e.g. cache | 
 | 	  validation. | 
 |  | 
 | config SLUB_DEBUG_ON | 
 | 	bool "SLUB debugging on by default" | 
 | 	depends on SLUB_DEBUG | 
 | 	select STACKDEPOT_ALWAYS_INIT if STACKTRACE_SUPPORT | 
 | 	default n | 
 | 	help | 
 | 	  Boot with debugging on by default. SLUB boots by default with | 
 | 	  the runtime debug capabilities switched off. Enabling this is | 
 | 	  equivalent to specifying the "slab_debug" parameter on boot. | 
 | 	  There is no support for more fine grained debug control like | 
 | 	  possible with slab_debug=xxx. SLUB debugging may be switched | 
 | 	  off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying | 
 | 	  "slab_debug=-". | 
 |  | 
 | config SLUB_RCU_DEBUG | 
 | 	bool "Enable UAF detection in TYPESAFE_BY_RCU caches (for KASAN)" | 
 | 	depends on SLUB_DEBUG | 
 | 	# SLUB_RCU_DEBUG should build fine without KASAN, but is currently useless | 
 | 	# without KASAN, so mark it as a dependency of KASAN for now. | 
 | 	depends on KASAN | 
 | 	default KASAN_GENERIC || KASAN_SW_TAGS | 
 | 	help | 
 | 	  Make SLAB_TYPESAFE_BY_RCU caches behave approximately as if the cache | 
 | 	  was not marked as SLAB_TYPESAFE_BY_RCU and every caller used | 
 | 	  kfree_rcu() instead. | 
 |  | 
 | 	  This is intended for use in combination with KASAN, to enable KASAN to | 
 | 	  detect use-after-free accesses in such caches. | 
 | 	  (KFENCE is able to do that independent of this flag.) | 
 |  | 
 | 	  This might degrade performance. | 
 | 	  Unfortunately this also prevents a very specific bug pattern from | 
 | 	  triggering (insufficient checks against an object being recycled | 
 | 	  within the RCU grace period); so this option can be turned off even on | 
 | 	  KASAN builds, in case you want to test for such a bug. | 
 |  | 
 | 	  If you're using this for testing bugs / fuzzing and care about | 
 | 	  catching all the bugs WAY more than performance, you might want to | 
 | 	  also turn on CONFIG_RCU_STRICT_GRACE_PERIOD. | 
 |  | 
 | 	  WARNING: | 
 | 	  This is designed as a debugging feature, not a security feature. | 
 | 	  Objects are sometimes recycled without RCU delay under memory pressure. | 
 |  | 
 | 	  If unsure, say N. | 
 |  | 
 | config PAGE_OWNER | 
 | 	bool "Track page owner" | 
 | 	depends on DEBUG_KERNEL && STACKTRACE_SUPPORT | 
 | 	select DEBUG_FS | 
 | 	select STACKTRACE | 
 | 	select STACKDEPOT | 
 | 	select PAGE_EXTENSION | 
 | 	help | 
 | 	  This keeps track of what call chain is the owner of a page, may | 
 | 	  help to find bare alloc_page(s) leaks. Even if you include this | 
 | 	  feature on your build, it is disabled in default. You should pass | 
 | 	  "page_owner=on" to boot parameter in order to enable it. Eats | 
 | 	  a fair amount of memory if enabled. See tools/mm/page_owner_sort.c | 
 | 	  for user-space helper. | 
 |  | 
 | 	  If unsure, say N. | 
 |  | 
 | config PAGE_TABLE_CHECK | 
 | 	bool "Check for invalid mappings in user page tables" | 
 | 	depends on ARCH_SUPPORTS_PAGE_TABLE_CHECK | 
 | 	depends on EXCLUSIVE_SYSTEM_RAM | 
 | 	select PAGE_EXTENSION | 
 | 	help | 
 | 	  Check that anonymous page is not being mapped twice with read write | 
 | 	  permissions. Check that anonymous and file pages are not being | 
 | 	  erroneously shared. Since the checking is performed at the time | 
 | 	  entries are added and removed to user page tables, leaking, corruption | 
 | 	  and double mapping problems are detected synchronously. | 
 |  | 
 | 	  If unsure say "n". | 
 |  | 
 | config PAGE_TABLE_CHECK_ENFORCED | 
 | 	bool "Enforce the page table checking by default" | 
 | 	depends on PAGE_TABLE_CHECK | 
 | 	help | 
 | 	  Always enable page table checking.  By default the page table checking | 
 | 	  is disabled, and can be optionally enabled via page_table_check=on | 
 | 	  kernel parameter. This config enforces that page table check is always | 
 | 	  enabled. | 
 |  | 
 | 	  If unsure say "n". | 
 |  | 
 | config PAGE_POISONING | 
 | 	bool "Poison pages after freeing" | 
 | 	help | 
 | 	  Fill the pages with poison patterns after free_pages() and verify | 
 | 	  the patterns before alloc_pages. The filling of the memory helps | 
 | 	  reduce the risk of information leaks from freed data. This does | 
 | 	  have a potential performance impact if enabled with the | 
 | 	  "page_poison=1" kernel boot option. | 
 |  | 
 | 	  Note that "poison" here is not the same thing as the "HWPoison" | 
 | 	  for CONFIG_MEMORY_FAILURE. This is software poisoning only. | 
 |  | 
 | 	  If you are only interested in sanitization of freed pages without | 
 | 	  checking the poison pattern on alloc, you can boot the kernel with | 
 | 	  "init_on_free=1" instead of enabling this. | 
 |  | 
 | 	  If unsure, say N | 
 |  | 
 | config DEBUG_PAGE_REF | 
 | 	bool "Enable tracepoint to track down page reference manipulation" | 
 | 	depends on DEBUG_KERNEL | 
 | 	depends on TRACEPOINTS | 
 | 	help | 
 | 	  This is a feature to add tracepoint for tracking down page reference | 
 | 	  manipulation. This tracking is useful to diagnose functional failure | 
 | 	  due to migration failures caused by page reference mismatches.  Be | 
 | 	  careful when enabling this feature because it adds about 30 KB to the | 
 | 	  kernel code.  However the runtime performance overhead is virtually | 
 | 	  nil until the tracepoints are actually enabled. | 
 |  | 
 | config DEBUG_RODATA_TEST | 
 |     bool "Testcase for the marking rodata read-only" | 
 |     depends on STRICT_KERNEL_RWX | 
 | 	help | 
 |       This option enables a testcase for the setting rodata read-only. | 
 |  | 
 | config ARCH_HAS_DEBUG_WX | 
 | 	bool | 
 |  | 
 | config DEBUG_WX | 
 | 	bool "Warn on W+X mappings at boot" | 
 | 	depends on ARCH_HAS_DEBUG_WX | 
 | 	depends on MMU | 
 | 	select PTDUMP_CORE | 
 | 	help | 
 | 	  Generate a warning if any W+X mappings are found at boot. | 
 |  | 
 | 	  This is useful for discovering cases where the kernel is leaving W+X | 
 | 	  mappings after applying NX, as such mappings are a security risk. | 
 |  | 
 | 	  Look for a message in dmesg output like this: | 
 |  | 
 | 	    <arch>/mm: Checked W+X mappings: passed, no W+X pages found. | 
 |  | 
 | 	  or like this, if the check failed: | 
 |  | 
 | 	    <arch>/mm: Checked W+X mappings: failed, <N> W+X pages found. | 
 |  | 
 | 	  Note that even if the check fails, your kernel is possibly | 
 | 	  still fine, as W+X mappings are not a security hole in | 
 | 	  themselves, what they do is that they make the exploitation | 
 | 	  of other unfixed kernel bugs easier. | 
 |  | 
 | 	  There is no runtime or memory usage effect of this option | 
 | 	  once the kernel has booted up - it's a one time check. | 
 |  | 
 | 	  If in doubt, say "Y". | 
 |  | 
 | config GENERIC_PTDUMP | 
 | 	bool | 
 |  | 
 | config PTDUMP_CORE | 
 | 	bool | 
 |  | 
 | config PTDUMP_DEBUGFS | 
 | 	bool "Export kernel pagetable layout to userspace via debugfs" | 
 | 	depends on DEBUG_KERNEL | 
 | 	depends on DEBUG_FS | 
 | 	depends on GENERIC_PTDUMP | 
 | 	select PTDUMP_CORE | 
 | 	help | 
 | 	  Say Y here if you want to show the kernel pagetable layout in a | 
 | 	  debugfs file. This information is only useful for kernel developers | 
 | 	  who are working in architecture specific areas of the kernel. | 
 | 	  It is probably not a good idea to enable this feature in a production | 
 | 	  kernel. | 
 |  | 
 | 	  If in doubt, say N. | 
 |  | 
 | config HAVE_DEBUG_KMEMLEAK | 
 | 	bool | 
 |  | 
 | config DEBUG_KMEMLEAK | 
 | 	bool "Kernel memory leak detector" | 
 | 	depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK | 
 | 	select DEBUG_FS | 
 | 	select STACKTRACE if STACKTRACE_SUPPORT | 
 | 	select KALLSYMS | 
 | 	select CRC32 | 
 | 	select STACKDEPOT | 
 | 	select STACKDEPOT_ALWAYS_INIT if !DEBUG_KMEMLEAK_DEFAULT_OFF | 
 | 	help | 
 | 	  Say Y here if you want to enable the memory leak | 
 | 	  detector. The memory allocation/freeing is traced in a way | 
 | 	  similar to the Boehm's conservative garbage collector, the | 
 | 	  difference being that the orphan objects are not freed but | 
 | 	  only shown in /sys/kernel/debug/kmemleak. Enabling this | 
 | 	  feature will introduce an overhead to memory | 
 | 	  allocations. See Documentation/dev-tools/kmemleak.rst for more | 
 | 	  details. | 
 |  | 
 | 	  Enabling SLUB_DEBUG may increase the chances of finding leaks | 
 | 	  due to the slab objects poisoning. | 
 |  | 
 | 	  In order to access the kmemleak file, debugfs needs to be | 
 | 	  mounted (usually at /sys/kernel/debug). | 
 |  | 
 | config DEBUG_KMEMLEAK_MEM_POOL_SIZE | 
 | 	int "Kmemleak memory pool size" | 
 | 	depends on DEBUG_KMEMLEAK | 
 | 	range 200 1000000 | 
 | 	default 16000 | 
 | 	help | 
 | 	  Kmemleak must track all the memory allocations to avoid | 
 | 	  reporting false positives. Since memory may be allocated or | 
 | 	  freed before kmemleak is fully initialised, use a static pool | 
 | 	  of metadata objects to track such callbacks. After kmemleak is | 
 | 	  fully initialised, this memory pool acts as an emergency one | 
 | 	  if slab allocations fail. | 
 |  | 
 | config DEBUG_KMEMLEAK_DEFAULT_OFF | 
 | 	bool "Default kmemleak to off" | 
 | 	depends on DEBUG_KMEMLEAK | 
 | 	help | 
 | 	  Say Y here to disable kmemleak by default. It can then be enabled | 
 | 	  on the command line via kmemleak=on. | 
 |  | 
 | config DEBUG_KMEMLEAK_AUTO_SCAN | 
 | 	bool "Enable kmemleak auto scan thread on boot up" | 
 | 	default y | 
 | 	depends on DEBUG_KMEMLEAK | 
 | 	help | 
 | 	  Depending on the cpu, kmemleak scan may be cpu intensive and can | 
 | 	  stall user tasks at times. This option enables/disables automatic | 
 | 	  kmemleak scan at boot up. | 
 |  | 
 | 	  Say N here to disable kmemleak auto scan thread to stop automatic | 
 | 	  scanning. Disabling this option disables automatic reporting of | 
 | 	  memory leaks. | 
 |  | 
 | 	  If unsure, say Y. | 
 |  | 
 | config PER_VMA_LOCK_STATS | 
 | 	bool "Statistics for per-vma locks" | 
 | 	depends on PER_VMA_LOCK | 
 | 	help | 
 | 	  Say Y here to enable success, retry and failure counters of page | 
 | 	  faults handled under protection of per-vma locks. When enabled, the | 
 | 	  counters are exposed in /proc/vmstat. This information is useful for | 
 | 	  kernel developers to evaluate effectiveness of per-vma locks and to | 
 | 	  identify pathological cases. Counting these events introduces a small | 
 | 	  overhead in the page fault path. | 
 |  | 
 | 	  If in doubt, say N. |