linux-kernel - Re: [PATCH v2] Add kernel config option for fuzz testing.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+YEYYNv-=AgNthQvLkeK-8uEeRs4XEuRqphfZBhc2hc5g@mail.gmail.com>
Date:   Tue, 24 Mar 2020 11:37:07 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Jiri Slaby <jslaby@...e.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Matthew Garrett <mjg59@...gle.com>,
        Andi Kleen <ak@...ux.intel.com>,
        "Theodore Y . Ts'o" <tytso@....edu>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] Add kernel config option for fuzz testing.

On Sat, Mar 21, 2020 at 5:50 AM Tetsuo Handa
<penguin-kernel@...ove.sakura.ne.jp> wrote:
>
> On 2020/03/10 15:30, Dmitry Vyukov wrote:
> > Re making it a single config vs a set of fine-grained configs. I think
> > making it fine-grained is a proper way to do it, but the point Tetsuo
> > raised is very real and painful as well -- when a kernel developer
> > adds another option, they will not go and update configs on all
> > external testing systems. This problem is also common for "enable all
> > boot tests that can run on this kernel", or "configure a 'standard'
> > debug build". Currently doing these things require all of expertise,
> > sacred knowledge, checking all configs one-by-one as well as checking
> > every new kernel patch and that needs to be done by everybody doing
> > any kernel testing.
> > I wonder if this can be solved by doing fine-grained configs, but also
> > adding some umbrella uber-config that will select all of the
> > individual options. Config system allows this, right? With "select" or
> > "default if" clauses. What would be better: have the umbrella option
> > select all individual, or all individual default to y if umbrella is
> > selected?
>
> So, we have three questions.
>
> Q1: Can we agree with adding build-time branching (i.e. kernel config options) ?
>
>     I fear bugs (e.g. unexpectedly overwrting flag variables) in run-time
>     branching mechanisms. Build-time branching mechanisms cannot have such bugs.

My vote is for build config. It's simplest to configure (every testing
system should already have control over config) and most reliable
(e.g. fuzzer figures out a way to disable a runtime option).


> Q2: If we can agree with kernel config options, can we start with single (or
>     fewer) kernel config option (e.g. CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING=y) ?
>
> Q3: If we can agree with kernel config options but we can't start with single
>     (or fewer) kernel config option, can we agree with adding another kernel
>     config option which selects all options (e.g.
>
>       config KERNEL_BUILT_FOR_FUZZ_TESTING
>              bool "Build kernel for fuzz testing"
>
>       config KERNEL_BUILT_FOR_FUZZ_TESTING_SELECT_ALL
>              bool "Select all options for Build kernel for fuzz testing"
>              depends on KERNEL_BUILT_FOR_FUZZ_TESTING
>              select KERNEL_DISABLE_FOO1
>              select KERNEL_DISABLE_BAR1
>              select KERNEL_DISABLE_BUZ1
>              select KERNEL_CHANGE_FOO2
>              select KERNEL_ENABLE_BAR2
>
>       config KERNEL_DISABLE_FOO1
>              bool "Disable foo1"
>              depends on KERNEL_BUILT_FOR_FUZZ_TESTING
>
>       config KERNEL_DISABLE_BAR1
>              bool "Disable bar1"
>              depends on KERNEL_BUILT_FOR_FUZZ_TESTING
>
>       config KERNEL_DISABLE_BUZ1
>              bool "Disable buz1"
>              depends on KERNEL_BUILT_FOR_FUZZ_TESTING
>
>       config KERNEL_CHANGE_FOO2
>              bool "Change foo2"
>              depends on KERNEL_BUILT_FOR_FUZZ_TESTING
>
>       config KERNEL_ENABLE_BAR2
>              bool "Enable bar2"
>              depends on KERNEL_BUILT_FOR_FUZZ_TESTING
>
>     ) ?

I think this option is the best. It both allows fine-grained control
(and documentation for each switch), and coarse-grained control for
testing systems.
We could also add "depends on DEBUG_KERNEL" just to make sure.