diff options
| -rw-r--r-- | lib/Kconfig.debug | 173 |
1 files changed, 89 insertions, 84 deletions
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 8526397f0688..e27c8ced3166 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -764,53 +764,6 @@ source "lib/Kconfig.kasan" endmenu # "Memory Debugging" -config ARCH_HAS_KCOV - bool - help - An architecture should select this when it can successfully - build and run with CONFIG_KCOV. This typically requires - disabling instrumentation for some early boot code. - -config CC_HAS_SANCOV_TRACE_PC - def_bool $(cc-option,-fsanitize-coverage=trace-pc) - -config KCOV - bool "Code coverage for fuzzing" - depends on ARCH_HAS_KCOV - depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS - select DEBUG_FS - select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC - help - KCOV exposes kernel code coverage information in a form suitable - for coverage-guided fuzzing (randomized testing). - - If RANDOMIZE_BASE is enabled, PC values will not be stable across - different machines and across reboots. If you need stable PC values, - disable RANDOMIZE_BASE. - - For more details, see Documentation/dev-tools/kcov.rst. - -config KCOV_ENABLE_COMPARISONS - bool "Enable comparison operands collection by KCOV" - depends on KCOV - depends on $(cc-option,-fsanitize-coverage=trace-cmp) - help - KCOV also exposes operands of every comparison in the instrumented - code along with operand sizes and PCs of the comparison instructions. - These operands can be used by fuzzing engines to improve the quality - of fuzzing coverage. - -config KCOV_INSTRUMENT_ALL - bool "Instrument all code by default" - depends on KCOV - default y - help - If you are doing generic system call fuzzing (like e.g. syzkaller), - then you will want to instrument the whole kernel and you should - say y here. If you are doing more targeted fuzzing (like e.g. - filesystem fuzzing with AFL) then you will want to enable coverage - for more specific subsets of files, and should say n here. - config DEBUG_SHIRQ bool "Debug shared IRQ handlers" depends on DEBUG_KERNEL @@ -1480,6 +1433,54 @@ config CPU_HOTPLUG_STATE_CONTROL Say N if your are unsure. +config LATENCYTOP + bool "Latency measuring infrastructure" + depends on DEBUG_KERNEL + depends on STACKTRACE_SUPPORT + depends on PROC_FS + select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86 + select KALLSYMS + select KALLSYMS_ALL + select STACKTRACE + select SCHEDSTATS + select SCHED_DEBUG + help + Enable this option if you want to use the LatencyTOP tool + to find out which userspace is blocking on what kernel operations. + +source "kernel/trace/Kconfig" + +config PROVIDE_OHCI1394_DMA_INIT + bool "Remote debugging over FireWire early on boot" + depends on PCI && X86 + help + If you want to debug problems which hang or crash the kernel early + on boot and the crashing machine has a FireWire port, you can use + this feature to remotely access the memory of the crashed machine + over FireWire. This employs remote DMA as part of the OHCI1394 + specification which is now the standard for FireWire controllers. + + With remote DMA, you can monitor the printk buffer remotely using + firescope and access all memory below 4GB using fireproxy from gdb. + Even controlling a kernel debugger is possible using remote DMA. + + Usage: + + If ohci1394_dma=early is used as boot parameter, it will initialize + all OHCI1394 controllers which are found in the PCI config space. + + As all changes to the FireWire bus such as enabling and disabling + devices cause a bus reset and thereby disable remote DMA for all + devices, be sure to have the cable plugged and FireWire enabled on + the debugging host before booting the debug target for debugging. + + This code (~1k) is freed after boot. By then, the firewire stack + in charge of the OHCI-1394 controllers should be used instead. + + See Documentation/debugging-via-ohci1394.txt for more information. + +source "lib/kunit/Kconfig" + config NOTIFIER_ERROR_INJECTION tristate "Notifier error injection" depends on DEBUG_KERNEL @@ -1638,53 +1639,57 @@ config FAULT_INJECTION_STACKTRACE_FILTER help Provide stacktrace filter for fault-injection capabilities -config LATENCYTOP - bool "Latency measuring infrastructure" - depends on DEBUG_KERNEL - depends on STACKTRACE_SUPPORT - depends on PROC_FS - select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86 - select KALLSYMS - select KALLSYMS_ALL - select STACKTRACE - select SCHEDSTATS - select SCHED_DEBUG - help - Enable this option if you want to use the LatencyTOP tool - to find out which userspace is blocking on what kernel operations. +endmenu # "Kernel Testing and Coverage" -source "kernel/trace/Kconfig" +menu "Kernel Testing and Coverage" -config PROVIDE_OHCI1394_DMA_INIT - bool "Remote debugging over FireWire early on boot" - depends on PCI && X86 +config ARCH_HAS_KCOV + bool help - If you want to debug problems which hang or crash the kernel early - on boot and the crashing machine has a FireWire port, you can use - this feature to remotely access the memory of the crashed machine - over FireWire. This employs remote DMA as part of the OHCI1394 - specification which is now the standard for FireWire controllers. + An architecture should select this when it can successfully + build and run with CONFIG_KCOV. This typically requires + disabling instrumentation for some early boot code. - With remote DMA, you can monitor the printk buffer remotely using - firescope and access all memory below 4GB using fireproxy from gdb. - Even controlling a kernel debugger is possible using remote DMA. +config CC_HAS_SANCOV_TRACE_PC + def_bool $(cc-option,-fsanitize-coverage=trace-pc) - Usage: - If ohci1394_dma=early is used as boot parameter, it will initialize - all OHCI1394 controllers which are found in the PCI config space. +config KCOV + bool "Code coverage for fuzzing" + depends on ARCH_HAS_KCOV + depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS + select DEBUG_FS + select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC + help + KCOV exposes kernel code coverage information in a form suitable + for coverage-guided fuzzing (randomized testing). - As all changes to the FireWire bus such as enabling and disabling - devices cause a bus reset and thereby disable remote DMA for all - devices, be sure to have the cable plugged and FireWire enabled on - the debugging host before booting the debug target for debugging. + If RANDOMIZE_BASE is enabled, PC values will not be stable across + different machines and across reboots. If you need stable PC values, + disable RANDOMIZE_BASE. - This code (~1k) is freed after boot. By then, the firewire stack - in charge of the OHCI-1394 controllers should be used instead. + For more details, see Documentation/dev-tools/kcov.rst. - See Documentation/debugging-via-ohci1394.txt for more information. +config KCOV_ENABLE_COMPARISONS + bool "Enable comparison operands collection by KCOV" + depends on KCOV + depends on $(cc-option,-fsanitize-coverage=trace-cmp) + help + KCOV also exposes operands of every comparison in the instrumented + code along with operand sizes and PCs of the comparison instructions. + These operands can be used by fuzzing engines to improve the quality + of fuzzing coverage. -source "lib/kunit/Kconfig" +config KCOV_INSTRUMENT_ALL + bool "Instrument all code by default" + depends on KCOV + default y + help + If you are doing generic system call fuzzing (like e.g. syzkaller), + then you will want to instrument the whole kernel and you should + say y here. If you are doing more targeted fuzzing (like e.g. + filesystem fuzzing with AFL) then you will want to enable coverage + for more specific subsets of files, and should say n here. menuconfig RUNTIME_TESTING_MENU bool "Runtime Testing" |