Commit 09a74952 authored by Changbin Du's avatar Changbin Du Committed by Linus Torvalds

kernel-hacking: move kernel testing and coverage options to same submenu

Move error injection, coverage, testing options to a new top level
submenu 'Kernel Testing and Coverage'.  They are all for test purpose.

Link: http://lkml.kernel.org/r/20190909144453.3520-5-changbin.du@gmail.comSigned-off-by: default avatarChangbin Du <changbin.du@gmail.com>
Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Tested-by: default avatarRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
parent 3be5cbcd
...@@ -764,53 +764,6 @@ source "lib/Kconfig.kasan" ...@@ -764,53 +764,6 @@ source "lib/Kconfig.kasan"
endmenu # "Memory Debugging" 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 config DEBUG_SHIRQ
bool "Debug shared IRQ handlers" bool "Debug shared IRQ handlers"
depends on DEBUG_KERNEL depends on DEBUG_KERNEL
...@@ -1480,6 +1433,54 @@ config CPU_HOTPLUG_STATE_CONTROL ...@@ -1480,6 +1433,54 @@ config CPU_HOTPLUG_STATE_CONTROL
Say N if your are unsure. 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 config NOTIFIER_ERROR_INJECTION
tristate "Notifier error injection" tristate "Notifier error injection"
depends on DEBUG_KERNEL depends on DEBUG_KERNEL
...@@ -1638,53 +1639,57 @@ config FAULT_INJECTION_STACKTRACE_FILTER ...@@ -1638,53 +1639,57 @@ config FAULT_INJECTION_STACKTRACE_FILTER
help help
Provide stacktrace filter for fault-injection capabilities Provide stacktrace filter for fault-injection capabilities
config LATENCYTOP endmenu # "Kernel Testing and Coverage"
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" menu "Kernel Testing and Coverage"
config PROVIDE_OHCI1394_DMA_INIT config ARCH_HAS_KCOV
bool "Remote debugging over FireWire early on boot" bool
depends on PCI && X86
help help
If you want to debug problems which hang or crash the kernel early An architecture should select this when it can successfully
on boot and the crashing machine has a FireWire port, you can use build and run with CONFIG_KCOV. This typically requires
this feature to remotely access the memory of the crashed machine disabling instrumentation for some early boot code.
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 config CC_HAS_SANCOV_TRACE_PC
firescope and access all memory below 4GB using fireproxy from gdb. def_bool $(cc-option,-fsanitize-coverage=trace-pc)
Even controlling a kernel debugger is possible using remote DMA.
Usage:
If ohci1394_dma=early is used as boot parameter, it will initialize config KCOV
all OHCI1394 controllers which are found in the PCI config space. 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 If RANDOMIZE_BASE is enabled, PC values will not be stable across
devices cause a bus reset and thereby disable remote DMA for all different machines and across reboots. If you need stable PC values,
devices, be sure to have the cable plugged and FireWire enabled on disable RANDOMIZE_BASE.
the debugging host before booting the debug target for debugging.
This code (~1k) is freed after boot. By then, the firewire stack For more details, see Documentation/dev-tools/kcov.rst.
in charge of the OHCI-1394 controllers should be used instead.
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 menuconfig RUNTIME_TESTING_MENU
bool "Runtime Testing" bool "Runtime Testing"
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment