Re: [PATCH] Kernel hacking menu: Runtime testing: keep tests together

[Kees Cook]

On Mon, Oct 2, 2017 at 10:48 AM, Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote:
> From: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
>
> Expand the "Runtime testing" menu by including more entries inside
> it instead of after it. This is just Kconfig symbol movement.

Thanks!

Acked-by: Kees Cook <keescook@xxxxxxxxxxxx>

-Kees

>
> This causes the (arch-independent) Runtime tests to be presented
> (listed) all in one place instead of in multiple places.
>
> Signed-off-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
> Cc: Kees Cook <keescook@xxxxxxxxxxxx>
> Cc: Dave Hansen <dave.hansen@xxxxxxxxx>
> Cc: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx>
> ---
>  lib/Kconfig.debug |  143 +++++++++++++++++++++-----------------------
>  1 file changed, 71 insertions(+), 72 deletions(-)
>
> --- lnx-414-rc3.orig/lib/Kconfig.debug
> +++ lnx-414-rc3/lib/Kconfig.debug
> @@ -1590,6 +1590,54 @@ config LATENCYTOP
>
>  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.
> +
> +config DMA_API_DEBUG
> +       bool "Enable debugging of DMA-API usage"
> +       depends on HAVE_DMA_API_DEBUG
> +       help
> +         Enable this option to debug the use of the DMA API by device drivers.
> +         With this option you will be able to detect common bugs in device
> +         drivers like double-freeing of DMA mappings or freeing mappings that
> +         were never allocated.
> +
> +         This also attempts to catch cases where a page owned by DMA is
> +         accessed by the cpu in a way that could cause data corruption.  For
> +         example, this enables cow_user_page() to check that the source page is
> +         not undergoing DMA.
> +
> +         This option causes a performance degradation.  Use only if you want to
> +         debug device drivers and dma interactions.
> +
> +         If unsure, say N.
> +
>  menu "Runtime Testing"
>
>  config LKDTM
> @@ -1749,56 +1797,6 @@ config TEST_PARMAN
>
>           If unsure, say N.
>
> -endmenu # runtime tests
> -
> -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.
> -
> -config DMA_API_DEBUG
> -       bool "Enable debugging of DMA-API usage"
> -       depends on HAVE_DMA_API_DEBUG
> -       help
> -         Enable this option to debug the use of the DMA API by device drivers.
> -         With this option you will be able to detect common bugs in device
> -         drivers like double-freeing of DMA mappings or freeing mappings that
> -         were never allocated.
> -
> -         This also attempts to catch cases where a page owned by DMA is
> -         accessed by the cpu in a way that could cause data corruption.  For
> -         example, this enables cow_user_page() to check that the source page is
> -         not undergoing DMA.
> -
> -         This option causes a performance degradation.  Use only if you want to
> -         debug device drivers and dma interactions.
> -
> -         If unsure, say N.
> -
>  config TEST_LKM
>         tristate "Test module loading with 'hello world' module"
>         default n
> @@ -1873,18 +1871,6 @@ config TEST_UDELAY
>
>           If unsure, say N.
>
> -config MEMTEST
> -       bool "Memtest"
> -       depends on HAVE_MEMBLOCK
> -       ---help---
> -         This option adds a kernel parameter 'memtest', which allows memtest
> -         to be set.
> -               memtest=0, mean disabled; -- default
> -               memtest=1, mean do 1 test pattern;
> -               ...
> -               memtest=17, mean do 17 test patterns.
> -         If you are unsure how to answer this question, answer N.
> -
>  config TEST_STATIC_KEYS
>         tristate "Test static keys"
>         default n
> @@ -1894,16 +1880,6 @@ config TEST_STATIC_KEYS
>
>           If unsure, say N.
>
> -config BUG_ON_DATA_CORRUPTION
> -       bool "Trigger a BUG when data corruption is detected"
> -       select DEBUG_LIST
> -       help
> -         Select this option if the kernel should BUG when it encounters
> -         data corruption in kernel memory structures when they get checked
> -         for validity.
> -
> -         If unsure, say N.
> -
>  config TEST_KMOD
>         tristate "kmod stress tester"
>         default n
> @@ -1941,6 +1917,29 @@ config TEST_DEBUG_VIRTUAL
>
>           If unsure, say N.
>
> +endmenu # runtime tests
> +
> +config MEMTEST
> +       bool "Memtest"
> +       depends on HAVE_MEMBLOCK
> +       ---help---
> +         This option adds a kernel parameter 'memtest', which allows memtest
> +         to be set.
> +               memtest=0, mean disabled; -- default
> +               memtest=1, mean do 1 test pattern;
> +               ...
> +               memtest=17, mean do 17 test patterns.
> +         If you are unsure how to answer this question, answer N.
> +
> +config BUG_ON_DATA_CORRUPTION
> +       bool "Trigger a BUG when data corruption is detected"
> +       select DEBUG_LIST
> +       help
> +         Select this option if the kernel should BUG when it encounters
> +         data corruption in kernel memory structures when they get checked
> +         for validity.
> +
> +         If unsure, say N.
>
>  source "samples/Kconfig"
>
>
>



-- 
Kees Cook
Pixel Security