123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168 |
- # 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 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/vm/page_owner_sort.c
- for user-space helper.
- If unsure, say N.
- config PAGE_PINNER
- bool "Track page pinner"
- 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 pinner of a page, may
- help to find page migration failures. Even if you include this
- feature in your build, it is disabled by default. You should pass
- "page_pinner=on" to boot parameter in order to enable it. Eats
- a fair amount of memory if 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.
|