From: Kees Cook <keescook@chromium.org>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Luis Rodriguez <mcgrof@kernel.org>,
Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH] Kernel hacking menu: Runtime testing: keep tests together
Date: Mon, 2 Oct 2017 11:10:46 -0700 [thread overview]
Message-ID: <CAGXu5jJfpOFs-T7qeGc4tf0GMu54uxNKPZmrTkk5O4kfZx=E4Q@mail.gmail.com> (raw)
In-Reply-To: <c194e5c4-2042-bf94-a2d8-7aa13756e257@infradead.org>
On Mon, Oct 2, 2017 at 10:48 AM, Randy Dunlap <rdunlap@infradead.org> wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> 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@chromium.org>
-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@infradead.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>
> ---
> 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
prev parent reply other threads:[~2017-10-02 18:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-02 17:48 [PATCH] Kernel hacking menu: Runtime testing: keep tests together Randy Dunlap
2017-10-02 18:10 ` Kees Cook [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGXu5jJfpOFs-T7qeGc4tf0GMu54uxNKPZmrTkk5O4kfZx=E4Q@mail.gmail.com' \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=rdunlap@infradead.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).