Messages in this thread | | | Subject | Re: [PATCH v2] Add kernel config option for fuzz testing. | From | Tetsuo Handa <> | Date | Thu, 26 Mar 2020 20:10:01 +0900 |
| |
On 2020/03/24 19:37, Dmitry Vyukov wrote: >> 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).
Right. For example, console loglevel has been unexpectedly changed via syscall arguments. For another example, /dev/mem has been unexpectedly accessed using mount operation ( https://github.com/google/syzkaller/issues/1436 ). Providing an interface (e.g. debugfs files) for branching after boot has a risk of unexpectedly overwriting flag variables.
Since it seems that there is no objection to Q1, I think that we can go with build-time branching.
>> 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. >> ) ? > > 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. >
OK. But I think that KERNEL_BUILT_FOR_FUZZ_TESTING_SELECT_ALL might fail to work, for it is possible that a new option was added but that option was not added to "select" list of KERNEL_BUILT_FOR_FUZZ_TESTING_SELECT_ALL. Also, there might be cases where a new option was added but that option should not be selected for some fuzzers (e.g. syzkaller wants to hardcode console loglevel to foo while fuzzer1 and fuzzer2 want to hardcode console loglevel to bar). That is, something like
config KERNEL_BUILT_FOR_FUZZ_TESTING bool "Build kernel for fuzz testing"
config KERNEL_BUILT_FOR_SYZKALLER bool "Build kernel for syzkaller testing" depends on KERNEL_BUILT_FOR_FUZZ_TESTING select KERNEL_DISABLE_FOO1 select KERNEL_DISABLE_BAR1 select KERNEL_DISABLE_BUZ1 select KERNEL_ENABLE_BAR2
config KERNEL_BUILT_FOR_FUZZER1 bool "Build kernel for fuzzer1 testing" depends on KERNEL_BUILT_FOR_FUZZ_TESTING select KERNEL_DISABLE_FOO1 select KERNEL_DISABLE_BAR1
config KERNEL_BUILT_FOR_FUZZER2 bool "Build kernel for fuzzer2 testing" depends on KERNEL_BUILT_FOR_FUZZ_TESTING select KERNEL_DISABLE_FOO1 select KERNEL_DISABLE_BUZ1
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
in order to allow each testing system to select what it wants with "only two options" ("CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING=y" and one of "CONFIG_KERNEL_BUILT_FOR_SYZKALLER=y" or "CONFIG_KERNEL_BUILT_FOR_FUZZER1=y" or "CONFIG_KERNEL_BUILT_FOR_FUZZER2=y").
CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING option remains there in order to avoid needlessly prompting choices to users who do not intend to build for fuzz testing.
| |