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

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.com


Signed-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

lib/Kconfig.debug

+89 −84
Original line number Diff line number Diff line
@@ -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"