* [PATCH v3] Add kernel config option for tweaking kernel behavior. @ 2020-04-13 6:33 Tetsuo Handa 2020-04-13 8:14 ` Greg Kroah-Hartman 2020-04-13 18:13 ` Linus Torvalds 0 siblings, 2 replies; 11+ messages in thread From: Tetsuo Handa @ 2020-04-13 6:33 UTC (permalink / raw) To: Andrew Morton Cc: Matthew Garrett, Andi Kleen, Theodore Y . Ts'o, Greg Kroah-Hartman, Alexander Viro, Petr Mladek, Sergey Senozhatsky, Arnd Bergmann, Jiri Slaby, Steven Rostedt, Linus Torvalds, Peter Zijlstra, LKML, Tetsuo Handa, Dmitry Vyukov Existing kernel config options are defined based on "whether you want to enable this module/feature or not". And such granularity is sometimes too rough-grained for fuzzing tools which try to find bugs inside each module/feature. While syzkaller (one of fuzzing tools) is finding many bugs, sometimes syzkaller examines stupid operations. Some examples of such operations are: changing console loglevel which in turn makes it impossible to get kernel messages when a crash happens, freezing filesystems which in turn causes khungtaskd to needlessly complain, programmatically sending Ctrl-Alt-Del which in turn causes the system to needlessly reboot. Currently we prevent syzkaller from examining stupid operations by blacklisting syscall arguments and/or disabling whole functionality using existing kernel config options. But such approach is difficult to maintain and needlessly prevents fuzzers from testing kernel code. [1] We want fuzzers to test as much coverage as possible while we want fuzzers not to try stupid operations. To achieve this goal, we want cooperation from kernel side, and build-time branching (i.e. kernel config options) will be the simplest and the most reliable. Therefore, this patch introduces a kernel config option which allows selecting fine-grained kernel config options for tweaking kernel's behavior. Each fine-grained kernel config option will be added by future patches. For ease of management, grouping kernel config options for allowing e.g. syzkaller to select all fine-grained kernel config options which e.g. syzkaller wants would be added by future patches. [1] https://lkml.kernel.org/r/CACT4Y+a6KExbggs4mg8pvoD554PcDqQNW4sM15X-tc=YONCzYw@mail.gmail.com Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Dmitry Vyukov <dvyukov@google.com> --- lib/Kconfig.debug | 11 +++++++++++ 1 file changed, 11 insertions(+) Changes since v2 ( https://lkml.kernel.org/r/20200307135822.3894-1-penguin-kernel@I-love.SAKURA.ne.jp ): Reduce the role of this kernel config option from "enable everything which would be useful for fuzz testing" to "simply serve as a gate for hiding individual kernel config option", for we should use individual kernel config option for tweaking individual kernel behavior. Changes since v1 ( https://lkml.kernel.org/r/20191216095955.9886-1-penguin-kernel@I-love.SAKURA.ne.jp ): Drop users of this kernel config option. Update patch description. diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 50c1f5f08e6f..a7c3ebc21428 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -2223,4 +2223,15 @@ config HYPERV_TESTING endmenu # "Kernel Testing and Coverage" +menuconfig TWEAK_KERNEL_BEHAVIOR + bool "Tweak kernel behavior" + help + Saying Y here allows modifying kernel behavior via kernel + config options which will become visible by selecting this + config option. + +if TWEAK_KERNEL_BEHAVIOR + +endif # TWEAK_KERNEL_BEHAVIOR + endmenu # Kernel hacking -- 2.18.2 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v3] Add kernel config option for tweaking kernel behavior. 2020-04-13 6:33 [PATCH v3] Add kernel config option for tweaking kernel behavior Tetsuo Handa @ 2020-04-13 8:14 ` Greg Kroah-Hartman 2020-04-18 14:28 ` Tetsuo Handa 2020-04-13 18:13 ` Linus Torvalds 1 sibling, 1 reply; 11+ messages in thread From: Greg Kroah-Hartman @ 2020-04-13 8:14 UTC (permalink / raw) To: Tetsuo Handa Cc: Andrew Morton, Matthew Garrett, Andi Kleen, Theodore Y . Ts'o, Alexander Viro, Petr Mladek, Sergey Senozhatsky, Arnd Bergmann, Jiri Slaby, Steven Rostedt, Linus Torvalds, Peter Zijlstra, LKML, Dmitry Vyukov On Mon, Apr 13, 2020 at 03:33:17PM +0900, Tetsuo Handa wrote: > Existing kernel config options are defined based on "whether you want to > enable this module/feature or not". And such granularity is sometimes > too rough-grained for fuzzing tools which try to find bugs inside each > module/feature. > > While syzkaller (one of fuzzing tools) is finding many bugs, sometimes > syzkaller examines stupid operations. Some examples of such operations > are: changing console loglevel which in turn makes it impossible to get > kernel messages when a crash happens, freezing filesystems which in turn > causes khungtaskd to needlessly complain, programmatically sending > Ctrl-Alt-Del which in turn causes the system to needlessly reboot. > Currently we prevent syzkaller from examining stupid operations by > blacklisting syscall arguments and/or disabling whole functionality > using existing kernel config options. But such approach is difficult to > maintain and needlessly prevents fuzzers from testing kernel code. [1] > > We want fuzzers to test as much coverage as possible while we want > fuzzers not to try stupid operations. To achieve this goal, we want > cooperation from kernel side, and build-time branching (i.e. kernel > config options) will be the simplest and the most reliable. > > Therefore, this patch introduces a kernel config option which allows > selecting fine-grained kernel config options for tweaking kernel's > behavior. Each fine-grained kernel config option will be added by future > patches. For ease of management, grouping kernel config options for > allowing e.g. syzkaller to select all fine-grained kernel config options > which e.g. syzkaller wants would be added by future patches. > > [1] https://lkml.kernel.org/r/CACT4Y+a6KExbggs4mg8pvoD554PcDqQNW4sM15X-tc=YONCzYw@mail.gmail.com > > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> > Cc: Dmitry Vyukov <dvyukov@google.com> > --- > lib/Kconfig.debug | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > Changes since v2 ( https://lkml.kernel.org/r/20200307135822.3894-1-penguin-kernel@I-love.SAKURA.ne.jp ): > Reduce the role of this kernel config option from "enable everything > which would be useful for fuzz testing" to "simply serve as a gate for > hiding individual kernel config option", for we should use individual > kernel config option for tweaking individual kernel behavior. > > Changes since v1 ( https://lkml.kernel.org/r/20191216095955.9886-1-penguin-kernel@I-love.SAKURA.ne.jp ): > Drop users of this kernel config option. > Update patch description. > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 50c1f5f08e6f..a7c3ebc21428 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -2223,4 +2223,15 @@ config HYPERV_TESTING > > endmenu # "Kernel Testing and Coverage" > > +menuconfig TWEAK_KERNEL_BEHAVIOR > + bool "Tweak kernel behavior" > + help > + Saying Y here allows modifying kernel behavior via kernel > + config options which will become visible by selecting this > + config option. This "help" text really only says "say Y here to allow for some config options". It doesn't explain what these are for, or why anyone would select them, or what type of options are here at all. I don't see how this option, by just looking at it, relates to your goal of doing things to make fuzzers' lives easier. thanks, greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v3] Add kernel config option for tweaking kernel behavior. 2020-04-13 8:14 ` Greg Kroah-Hartman @ 2020-04-18 14:28 ` Tetsuo Handa 2020-04-18 14:39 ` Greg Kroah-Hartman 0 siblings, 1 reply; 11+ messages in thread From: Tetsuo Handa @ 2020-04-18 14:28 UTC (permalink / raw) To: Greg Kroah-Hartman, Linus Torvalds Cc: Andrew Morton, Matthew Garrett, Andi Kleen, Theodore Y . Ts'o, Alexander Viro, Petr Mladek, Sergey Senozhatsky, Arnd Bergmann, Jiri Slaby, Steven Rostedt, Peter Zijlstra, LKML, Dmitry Vyukov On 2020/04/13 17:14, Greg Kroah-Hartman wrote: >> @@ -2223,4 +2223,15 @@ config HYPERV_TESTING >> >> endmenu # "Kernel Testing and Coverage" >> >> +menuconfig TWEAK_KERNEL_BEHAVIOR >> + bool "Tweak kernel behavior" >> + help >> + Saying Y here allows modifying kernel behavior via kernel >> + config options which will become visible by selecting this >> + config option. > > This "help" text really only says "say Y here to allow for some config > options". It doesn't explain what these are for, or why anyone would > select them, or what type of options are here at all. > > I don't see how this option, by just looking at it, relates to your goal > of doing things to make fuzzers' lives easier. Well, we could add some more text (like shown below), but this option itself is neutral. This option is not limiting the target to fuzzers. Below 3 patches are an example of "a set of fine-grained configs" with "some umbrella uber-config" approach. Linus, are you OK with this approach? From 23b585fdd0ed55710285a6d67faffe63cebc098f Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Date: Sat, 18 Apr 2020 22:03:04 +0900 Subject: [PATCH 1/3] Add kernel config option for tweaking kernel behavior. Existing kernel config options are defined based on "whether you want to enable this module/feature or not". And such granularity is sometimes too rough-grained for fuzzing tools which try to find bugs inside each module/feature. While syzkaller (one of fuzzing tools) is finding many bugs, sometimes syzkaller examines stupid operations. Some examples of such operations are: changing console loglevel which in turn makes it impossible to get kernel messages when a crash happens, freezing filesystems which in turn causes khungtaskd to needlessly complain, programmatically sending Ctrl-Alt-Del which in turn causes the system to needlessly reboot. Currently we prevent syzkaller from examining stupid operations by blacklisting syscall arguments and/or disabling whole functionality using existing kernel config options. But such approach is difficult to maintain and needlessly prevents fuzzers from testing kernel code. [1] We want fuzzers to test as much coverage as possible while we want fuzzers not to try stupid operations. To achieve this goal, we want cooperation from kernel side, and build-time branching (i.e. kernel config options) will be the simplest and the most reliable. Therefore, this patch introduces a kernel config option which allows selecting fine-grained kernel config options for tweaking kernel's behavior. Each fine-grained kernel config option will be added by future patches. For ease of management, grouping kernel config options for allowing e.g. syzkaller to select all fine-grained kernel config options which e.g. syzkaller wants would be added by future patches. [1] https://lkml.kernel.org/r/CACT4Y+a6KExbggs4mg8pvoD554PcDqQNW4sM15X-tc=YONCzYw@mail.gmail.com Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> --- lib/Kconfig.debug | 2 ++ lib/Kconfig.tewak | 13 +++++++++++++ 2 files changed, 15 insertions(+) create mode 100644 lib/Kconfig.tewak diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 21d9c5f6e7ec..e6162595ef9d 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -2225,4 +2225,6 @@ config HYPERV_TESTING endmenu # "Kernel Testing and Coverage" +source "lib/Kconfig.tewak" + endmenu # Kernel hacking diff --git a/lib/Kconfig.tewak b/lib/Kconfig.tewak new file mode 100644 index 000000000000..a5ce0db67f28 --- /dev/null +++ b/lib/Kconfig.tewak @@ -0,0 +1,13 @@ +menuconfig TWEAK_KERNEL_BEHAVIOR + bool "Tweak kernel behavior" + help + Saying Y here allows modifying kernel behavior via kernel + config options which will become visible by selecting this + config option. Since these kernel config options are intended + for helping e.g. fuzz testing, behavior tweaked by this kernel + option might be unstable. Userspace applications should not + count on this option being selected. + +if TWEAK_KERNEL_BEHAVIOR + +endif # TWEAK_KERNEL_BEHAVIOR -- 2.18.2 From f7f668896e188217b50c50a31c4ad1acb7556b36 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Date: Sat, 18 Apr 2020 22:39:38 +0900 Subject: [PATCH 2/3] tweak: Allow disabling k_spec() function in drivers/tty/vt/keyboard.c syzbot is reporting unexpected kernel reboots [1]. This seems to be caused by triggering Ctrl-Alt-Del event via k_spec() function in drivers/tty/vt/keyboard.c file, for the console output includes normal restart sequence. Therefore, allow disabling only k_spec() function in order to allow fuzzers to examine the remaining part in that file. [1] https://syzkaller.appspot.com/bug?id=321861b1588b44d064b779b92293c5d55cfe8430 Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> --- drivers/tty/vt/keyboard.c | 2 ++ lib/Kconfig.tewak | 7 +++++++ 2 files changed, 9 insertions(+) diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c index 15d33fa0c925..f08855c4c5ba 100644 --- a/drivers/tty/vt/keyboard.c +++ b/drivers/tty/vt/keyboard.c @@ -633,6 +633,8 @@ static void k_spec(struct vc_data *vc, unsigned char value, char up_flag) kbd->kbdmode == VC_OFF) && value != KVAL(K_SAK)) return; /* SAK is allowed even in raw mode */ + if (IS_ENABLED(CONFIG_TWEAK_DISABLE_KBD_K_SPEC_HANDLER)) + return; fn_handler[value](vc); } diff --git a/lib/Kconfig.tewak b/lib/Kconfig.tewak index a5ce0db67f28..a1d038bcc2a5 100644 --- a/lib/Kconfig.tewak +++ b/lib/Kconfig.tewak @@ -10,4 +10,11 @@ menuconfig TWEAK_KERNEL_BEHAVIOR if TWEAK_KERNEL_BEHAVIOR +config TWEAK_DISABLE_KBD_K_SPEC_HANDLER + bool "Disable k_spec() function in drivers/tty/vt/keyboard.c" + help + k_spec() function allows triggering e.g. Ctrl-Alt-Del event. + Such event is annoying for fuzz testing which wants to test + kernel code without rebooting the system. + endif # TWEAK_KERNEL_BEHAVIOR -- 2.18.2 From 5cf7f2ef1d470ea980c6b9a21437d37279d13d12 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Date: Sat, 18 Apr 2020 23:12:16 +0900 Subject: [PATCH 3/3] tweak: Add option for selecting tweak options for syzkaller's testing When a kernel developer adds a kernel config 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. In order to reduce the burden of maintaining kernel config options, this patch introduces a kernel config option which will select tweak options when building kernels for syzkaller's testing. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Dmitry Vyukov <dvyukov@google.com> --- lib/Kconfig.tewak | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/lib/Kconfig.tewak b/lib/Kconfig.tewak index a1d038bcc2a5..95020a56bbfc 100644 --- a/lib/Kconfig.tewak +++ b/lib/Kconfig.tewak @@ -10,6 +10,12 @@ menuconfig TWEAK_KERNEL_BEHAVIOR if TWEAK_KERNEL_BEHAVIOR +config TWEAK_FOR_SYZKALLER_TESTING + bool "Select all tewak options suitable for syzkaller testing" + select TWEAK_DISABLE_KBD_K_SPEC_HANDLER + help + Say N unless you are building kernels for syzkaller's testing. + config TWEAK_DISABLE_KBD_K_SPEC_HANDLER bool "Disable k_spec() function in drivers/tty/vt/keyboard.c" help -- 2.18.2 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v3] Add kernel config option for tweaking kernel behavior. 2020-04-18 14:28 ` Tetsuo Handa @ 2020-04-18 14:39 ` Greg Kroah-Hartman 2020-04-18 15:08 ` Tetsuo Handa 0 siblings, 1 reply; 11+ messages in thread From: Greg Kroah-Hartman @ 2020-04-18 14:39 UTC (permalink / raw) To: Tetsuo Handa Cc: Linus Torvalds, Andrew Morton, Matthew Garrett, Andi Kleen, Theodore Y . Ts'o, Alexander Viro, Petr Mladek, Sergey Senozhatsky, Arnd Bergmann, Jiri Slaby, Steven Rostedt, Peter Zijlstra, LKML, Dmitry Vyukov On Sat, Apr 18, 2020 at 11:28:22PM +0900, Tetsuo Handa wrote: > On 2020/04/13 17:14, Greg Kroah-Hartman wrote: > >> @@ -2223,4 +2223,15 @@ config HYPERV_TESTING > >> > >> endmenu # "Kernel Testing and Coverage" > >> > >> +menuconfig TWEAK_KERNEL_BEHAVIOR > >> + bool "Tweak kernel behavior" > >> + help > >> + Saying Y here allows modifying kernel behavior via kernel > >> + config options which will become visible by selecting this > >> + config option. > > > > This "help" text really only says "say Y here to allow for some config > > options". It doesn't explain what these are for, or why anyone would > > select them, or what type of options are here at all. > > > > I don't see how this option, by just looking at it, relates to your goal > > of doing things to make fuzzers' lives easier. > > Well, we could add some more text (like shown below), but this option itself > is neutral. This option is not limiting the target to fuzzers. > Below 3 patches are an example of "a set of fine-grained configs" with > "some umbrella uber-config" approach. Linus, are you OK with this approach? Note, the word "tweak" is usually used where people want to get the most performance out of a system, while here you are using it to remove functionality out of the system. You might want to pick a different word, naming is hard :( Anyway, a comment on your patch: > >From f7f668896e188217b50c50a31c4ad1acb7556b36 Mon Sep 17 00:00:00 2001 > From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> > Date: Sat, 18 Apr 2020 22:39:38 +0900 > Subject: [PATCH 2/3] tweak: Allow disabling k_spec() function in drivers/tty/vt/keyboard.c > > syzbot is reporting unexpected kernel reboots [1]. This seems to be > caused by triggering Ctrl-Alt-Del event via k_spec() function in > drivers/tty/vt/keyboard.c file, for the console output includes normal > restart sequence. Therefore, allow disabling only k_spec() function > in order to allow fuzzers to examine the remaining part in that file. > > [1] https://syzkaller.appspot.com/bug?id=321861b1588b44d064b779b92293c5d55cfe8430 > > Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> > --- > drivers/tty/vt/keyboard.c | 2 ++ > lib/Kconfig.tewak | 7 +++++++ > 2 files changed, 9 insertions(+) > > diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c > index 15d33fa0c925..f08855c4c5ba 100644 > --- a/drivers/tty/vt/keyboard.c > +++ b/drivers/tty/vt/keyboard.c > @@ -633,6 +633,8 @@ static void k_spec(struct vc_data *vc, unsigned char value, char up_flag) > kbd->kbdmode == VC_OFF) && > value != KVAL(K_SAK)) > return; /* SAK is allowed even in raw mode */ > + if (IS_ENABLED(CONFIG_TWEAK_DISABLE_KBD_K_SPEC_HANDLER)) > + return; Are you sure this is correct? It seems like you just cut off a number of other keyboard function handlers instead of just the ctrl-alt-del functionality. Did you really want to do that? thanks, greg k-h ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v3] Add kernel config option for tweaking kernel behavior. 2020-04-18 14:39 ` Greg Kroah-Hartman @ 2020-04-18 15:08 ` Tetsuo Handa 0 siblings, 0 replies; 11+ messages in thread From: Tetsuo Handa @ 2020-04-18 15:08 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Linus Torvalds, Andrew Morton, Matthew Garrett, Andi Kleen, Theodore Y . Ts'o, Alexander Viro, Petr Mladek, Sergey Senozhatsky, Arnd Bergmann, Jiri Slaby, Steven Rostedt, Peter Zijlstra, LKML, Dmitry Vyukov On 2020/04/18 23:39, Greg Kroah-Hartman wrote: >> Well, we could add some more text (like shown below), but this option itself >> is neutral. This option is not limiting the target to fuzzers. >> Below 3 patches are an example of "a set of fine-grained configs" with >> "some umbrella uber-config" approach. Linus, are you OK with this approach? > > Note, the word "tweak" is usually used where people want to get the most > performance out of a system, while here you are using it to remove > functionality out of the system. You might want to pick a different > word, naming is hard :( Then, what about "twist" ? >> @@ -633,6 +633,8 @@ static void k_spec(struct vc_data *vc, unsigned char value, char up_flag) >> kbd->kbdmode == VC_OFF) && >> value != KVAL(K_SAK)) >> return; /* SAK is allowed even in raw mode */ >> + if (IS_ENABLED(CONFIG_TWEAK_DISABLE_KBD_K_SPEC_HANDLER)) >> + return; > > Are you sure this is correct? It seems like you just cut off a number > of other keyboard function handlers instead of just the ctrl-alt-del > functionality. Did you really want to do that? Maybe someday we update this filter more fine-grained. But I think this granularity is what syzkaller wants for now. The ctrl-alt-del ( k_spec() => fn_boot_it() => ctrl_alt_del()) is simply one of them. There was RCU stall report caused by repeating SysRq-t from this path ( k_spec() => fn_show_state() => show_state()) due to too much printk() calls. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v3] Add kernel config option for tweaking kernel behavior. 2020-04-13 6:33 [PATCH v3] Add kernel config option for tweaking kernel behavior Tetsuo Handa 2020-04-13 8:14 ` Greg Kroah-Hartman @ 2020-04-13 18:13 ` Linus Torvalds 2020-04-14 8:02 ` Tetsuo Handa 2020-04-16 0:47 ` Tetsuo Handa 1 sibling, 2 replies; 11+ messages in thread From: Linus Torvalds @ 2020-04-13 18:13 UTC (permalink / raw) To: Tetsuo Handa Cc: Andrew Morton, Matthew Garrett, Andi Kleen, Theodore Y . Ts'o, Greg Kroah-Hartman, Alexander Viro, Petr Mladek, Sergey Senozhatsky, Arnd Bergmann, Jiri Slaby, Steven Rostedt, Peter Zijlstra, LKML, Dmitry Vyukov On Sun, Apr 12, 2020 at 11:34 PM Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote: > > Existing kernel config options are defined based on "whether you want to > enable this module/feature or not". And such granularity is sometimes > too rough-grained for fuzzing tools which try to find bugs inside each > module/feature. I still detest making this a hardcoded build-time config option. A kernel parameter that sets a flag seems much simpler. More importantly, having it be something sanely named, and something you can set independently some other way, would allow a regular kernel to then run a fuzzer as root. Some kind of "not even root" flag, which might be per-process and not possible to clear once set (so that your _normal_ system binaries could still do the root-only stuff, but then you could start a fuzzing process with that flag set, knowing that the fuzzing process - and it's children - are not able to do things). Honestly, in a perfect world, it has nothing at all to do with fuzzing, and people could even have some local rules like "anybody who came in through ssh from the network will also have this flag set". Linus ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v3] Add kernel config option for tweaking kernel behavior. 2020-04-13 18:13 ` Linus Torvalds @ 2020-04-14 8:02 ` Tetsuo Handa 2020-04-15 0:05 ` Tetsuo Handa 2020-04-16 0:47 ` Tetsuo Handa 1 sibling, 1 reply; 11+ messages in thread From: Tetsuo Handa @ 2020-04-14 8:02 UTC (permalink / raw) To: Linus Torvalds, Dmitry Vyukov Cc: Andrew Morton, Matthew Garrett, Andi Kleen, Theodore Y . Ts'o, Greg Kroah-Hartman, Alexander Viro, Petr Mladek, Sergey Senozhatsky, Arnd Bergmann, Jiri Slaby, Steven Rostedt, Peter Zijlstra, LKML On 2020/04/14 3:13, Linus Torvalds wrote: > On Sun, Apr 12, 2020 at 11:34 PM Tetsuo Handa > <penguin-kernel@i-love.sakura.ne.jp> wrote: >> >> Existing kernel config options are defined based on "whether you want to >> enable this module/feature or not". And such granularity is sometimes >> too rough-grained for fuzzing tools which try to find bugs inside each >> module/feature. > > I still detest making this a hardcoded build-time config option. > > A kernel parameter that sets a flag seems much simpler. More > importantly, having it be something sanely named, and something you > can set independently some other way, would allow a regular kernel to > then run a fuzzer as root. That approach involves declaration of user-visible behavioral ABI which will become impossible to change or remove if we once published. Also, syzkaller does not want to depend on userspace being rich. There are userspace tools (e.g. SystemTap) that can tweak kernel's behavior. If we could use SystemTap, we could do some of tweaks using SystemTap. Likewise, use of runtime flags which can be set from userspace involves modification of userspace programs, which is a sort of dependency syzkaller does not want to maintain. The advantage of build-time tweaking is that we don't need to maintain behavioral ABI. We can change what tweak is doing over time (e.g. narrowing down what the build-time tweaking guards, improving how to get more useful information). > > Some kind of "not even root" flag, which might be per-process and not > possible to clear once set (so that your _normal_ system binaries > could still do the root-only stuff, but then you could start a fuzzing > process with that flag set, knowing that the fuzzing process - and > it's children - are not able to do things). I don't think per-process flags will work. Not every action is taken inside process context who issued a syscall. Some action might be taken in interrupt context or in kthread context. Since we have no means to propagate per-process flags, we will need to give up more than we have to give up. > > Honestly, in a perfect world, it has nothing at all to do with > fuzzing, and people could even have some local rules like "anybody who > came in through ssh from the network will also have this flag set". I think that such restriction should be implemented as LSM modules. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v3] Add kernel config option for tweaking kernel behavior. 2020-04-14 8:02 ` Tetsuo Handa @ 2020-04-15 0:05 ` Tetsuo Handa 2020-04-15 1:14 ` Linus Torvalds 0 siblings, 1 reply; 11+ messages in thread From: Tetsuo Handa @ 2020-04-15 0:05 UTC (permalink / raw) To: Linus Torvalds Cc: Dmitry Vyukov, Andrew Morton, Matthew Garrett, Andi Kleen, Theodore Y . Ts'o, Greg Kroah-Hartman, Alexander Viro, Petr Mladek, Sergey Senozhatsky, Arnd Bergmann, Jiri Slaby, Steven Rostedt, Peter Zijlstra, LKML On 2020/04/14 17:02, Tetsuo Handa wrote: >> Some kind of "not even root" flag, which might be per-process and not >> possible to clear once set (so that your _normal_ system binaries >> could still do the root-only stuff, but then you could start a fuzzing >> process with that flag set, knowing that the fuzzing process - and >> it's children - are not able to do things). > > I don't think per-process flags will work. Not every action is taken inside > process context who issued a syscall. Some action might be taken in interrupt > context or in kthread context. Since we have no means to propagate per-process > flags, we will need to give up more than we have to give up. An example from https://syzkaller.appspot.com/bug?id=fc28634f4815322260d0735ad0ed14f767b558b6 (currently the third top crasher in "open" table). ------------[ cut here ]------------ WARNING: CPU: 1 PID: 3668 at net/core/dev.c:8776 rollback_registered_many+0x1ed/0xec0 net/core/dev.c:8776 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 3668 Comm: kworker/1:6 Not tainted 5.6.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xef/0x16e lib/dump_stack.c:118 panic+0x2aa/0x6e1 kernel/panic.c:221 __warn.cold+0x2f/0x30 kernel/panic.c:582 report_bug+0x27b/0x2f0 lib/bug.c:195 fixup_bug arch/x86/kernel/traps.c:174 [inline] fixup_bug arch/x86/kernel/traps.c:169 [inline] do_error_trap+0x12b/0x1e0 arch/x86/kernel/traps.c:267 do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:286 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027 RIP: 0010:rollback_registered_many+0x1ed/0xec0 net/core/dev.c:8776 Code: 05 00 00 31 ff 44 89 fe e8 10 ac 78 fc 45 84 ff 0f 85 49 ff ff ff e8 d2 aa 78 fc 0f 1f 44 00 00 e8 c8 aa 78 fc e8 c3 aa 78 fc <0f> 0b 48 89 ef e8 59 2e 24 fd 31 ff 89 c5 89 c6 e8 de ab 78 fc 40 RSP: 0018:ffff8881d4b7f640 EFLAGS: 00010216 RAX: 0000000000040000 RBX: ffff8881d1620000 RCX: ffffc9000d3f6000 RDX: 0000000000003912 RSI: ffffffff84c6ad5d RDI: 0000000000000001 RBP: ffff8881d1620068 R08: ffff8881c74d9880 R09: fffffbfff0f876c5 R10: fffffbfff0f876c4 R11: ffffffff87c3b627 R12: ffff8881d4b7f788 R13: dffffc0000000000 R14: ffff8881d4b7f720 R15: 0000000000000000 rollback_registered+0xf2/0x1c0 net/core/dev.c:8855 unregister_netdevice_queue net/core/dev.c:9947 [inline] unregister_netdevice_queue+0x1d7/0x2b0 net/core/dev.c:9940 unregister_netdevice include/linux/netdevice.h:2715 [inline] unregister_netdev+0x18/0x20 net/core/dev.c:9988 r871xu_dev_remove+0xe2/0x215 drivers/staging/rtl8712/usb_intf.c:604 usb_unbind_interface+0x1bd/0x8a0 drivers/usb/core/driver.c:436 __device_release_driver drivers/base/dd.c:1137 [inline] device_release_driver_internal+0x42f/0x500 drivers/base/dd.c:1168 bus_remove_device+0x2eb/0x5a0 drivers/base/bus.c:533 device_del+0x481/0xd30 drivers/base/core.c:2677 usb_disable_device+0x23d/0x790 drivers/usb/core/message.c:1238 usb_disconnect+0x293/0x900 drivers/usb/core/hub.c:2211 hub_port_connect drivers/usb/core/hub.c:5046 [inline] hub_port_connect_change drivers/usb/core/hub.c:5335 [inline] port_event drivers/usb/core/hub.c:5481 [inline] hub_event+0x1a1d/0x4300 drivers/usb/core/hub.c:5563 process_one_work+0x94b/0x1620 kernel/workqueue.c:2266 process_scheduled_works kernel/workqueue.c:2328 [inline] worker_thread+0x7ab/0xe20 kernel/workqueue.c:2414 kthread+0x318/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 8767 list_for_each_entry_safe(dev, tmp, head, unreg_list) { 8768 /* Some devices call without registering 8769 * for initialization unwind. Remove those 8770 * devices and proceed with the remaining. 8771 */ 8772 if (dev->reg_state == NETREG_UNINITIALIZED) { 8773 pr_debug("unregister_netdevice: device %s/%p never was registered\n", 8774 dev->name, dev); 8775 8776 WARN_ON(1); 8777 list_del(&dev->unreg_list); 8778 continue; 8779 } 8780 dev->dismantle = true; 8781 BUG_ON(dev->reg_state != NETREG_REGISTERED); 8782 } I can't judge whether this WARN_ON() makes sense outside of syzkaller. But I'd like to suppress this WARN_ON() under testing by syzkaller so that syzkaller can spend resource for seeking for different bugs (assuming that suppressing this WARN_ON() is harmless). To suppress this WARN_ON(), per-process flags (e.g. current->dont_hit_warn_on_at_rollback_registered_many ) cannot work because this is a Workqueue context. And user-visible global flags (e.g. sysctl_dont_hit_warn_on_at_rollback_registered_many ) is too much. An approach for TOMOYO to solve this kind of problem is to guard using a kernel config option for fuzz testing. commit e80b18599a39a625 ("tomoyo: Add a kernel config option for fuzzing testing.") commit 4ad98ac46490d5f8 ("tomoyo: Don't emit WARNING: string while fuzzing testing.") This is not something that should publish permanently user-visible flags. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v3] Add kernel config option for tweaking kernel behavior. 2020-04-15 0:05 ` Tetsuo Handa @ 2020-04-15 1:14 ` Linus Torvalds 2020-04-15 1:43 ` Steven Rostedt 0 siblings, 1 reply; 11+ messages in thread From: Linus Torvalds @ 2020-04-15 1:14 UTC (permalink / raw) To: Tetsuo Handa Cc: Dmitry Vyukov, Andrew Morton, Matthew Garrett, Andi Kleen, Theodore Y . Ts'o, Greg Kroah-Hartman, Alexander Viro, Petr Mladek, Sergey Senozhatsky, Arnd Bergmann, Jiri Slaby, Steven Rostedt, Peter Zijlstra, LKML On Tue, Apr 14, 2020 at 5:06 PM Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote: > > I can't judge whether this WARN_ON() makes sense outside of syzkaller. > But I'd like to suppress this WARN_ON() under testing by syzkaller so that > syzkaller can spend resource for seeking for different bugs (assuming that > suppressing this WARN_ON() is harmless). That's crazy talk. Either that WARN_ON() is valid, or it's not. It doesn't matter if it's syzcaller, and we would never change the behavior of it depending on a flag - compile-time or dynamic. There's no way we'd accept that as some "#ifndef CONFIG_FUZZER" thing either. If that WARN_ON() is a problem, then the people behind it should be appraised of it, and it should probably be removed. I'm assuming it was some kind of "I don't think this can happen, so if it does, I want to see how it happened" WARN_ON. Linus ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v3] Add kernel config option for tweaking kernel behavior. 2020-04-15 1:14 ` Linus Torvalds @ 2020-04-15 1:43 ` Steven Rostedt 0 siblings, 0 replies; 11+ messages in thread From: Steven Rostedt @ 2020-04-15 1:43 UTC (permalink / raw) To: Linus Torvalds Cc: Tetsuo Handa, Dmitry Vyukov, Andrew Morton, Matthew Garrett, Andi Kleen, Theodore Y . Ts'o, Greg Kroah-Hartman, Alexander Viro, Petr Mladek, Sergey Senozhatsky, Arnd Bergmann, Jiri Slaby, Peter Zijlstra, LKML On Tue, 14 Apr 2020 18:14:51 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote: > If that WARN_ON() is a problem, then the people behind it should be > appraised of it, and it should probably be removed. I'm assuming it > was some kind of "I don't think this can happen, so if it does, I want > to see how it happened" WARN_ON. What I do (and feel everyone should too), is I only add a WARN_ON() when I check something that I believe *can't* happen. If the WARN_ON() triggers, it either means that there's a bug in the code (and needs a fix), or the code design changed, in which case the WARN_ON() should be either removed, or that code updated to handle the new change. In any case, a WARN_ON() should always be investigated when hit. The only time I've had issues with people is when I have some hardware (i915) that triggers a WARN_ON() and I'm told that my hardware is buggy (or I need a firmware update). In which case, I just manually remove the WARN_ON() because the machine that triggers it is a test machine I don't have the time to waste updating firmware on. -- Steve ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v3] Add kernel config option for tweaking kernel behavior. 2020-04-13 18:13 ` Linus Torvalds 2020-04-14 8:02 ` Tetsuo Handa @ 2020-04-16 0:47 ` Tetsuo Handa 1 sibling, 0 replies; 11+ messages in thread From: Tetsuo Handa @ 2020-04-16 0:47 UTC (permalink / raw) To: Linus Torvalds Cc: Andrew Morton, Matthew Garrett, Andi Kleen, Theodore Y. Ts'o, Greg Kroah-Hartman, Alexander Viro, Petr Mladek, Sergey Senozhatsky, Arnd Bergmann, Jiri Slaby, Steven Rostedt, Peter Zijlstra, LKML, Dmitry Vyukov On 2020/04/14 3:13, Linus Torvalds wrote: > On Sun, Apr 12, 2020 at 11:34 PM Tetsuo Handa > <penguin-kernel@i-love.sakura.ne.jp> wrote: >> >> Existing kernel config options are defined based on "whether you want to >> enable this module/feature or not". And such granularity is sometimes >> too rough-grained for fuzzing tools which try to find bugs inside each >> module/feature. > > I still detest making this a hardcoded build-time config option. But I think that starting from build-time config option is the better. > > A kernel parameter that sets a flag seems much simpler. More > importantly, having it be something sanely named, and something you > can set independently some other way, would allow a regular kernel to > then run a fuzzer as root. We can't beforehand determine how many kernel parameters will be needed. I don't think the number of kernel parameters is "one". You said "I'd *much* rather see some way to just lock down certain things individually.". Also, different fuzzing mechanisms may want different set of things (e.g. current->do_not_emit_warning_string for syzkaller described bottom). But will the number of kernel parameters be "a few" ? "a dozen" ? "some dozen" ? "some hundreds" ? "one thousand" ? Of course, I'm not expecting "one thousand". But I can't say how many kernel parameters will be needed. The number of kernel parameters can be determined only after we identify what "things" we need to tweak. The first step is to identify which operation should be tweaked, and it will take *very long time*. I don't think that it is realistic to update userspace programs to support that flag whenever a new flag was added (with sane name and explanation for users who are not interested in running fuzzers on their kernels) in the kernel side. > > Some kind of "not even root" flag, which might be per-process and not > possible to clear once set (so that your _normal_ system binaries > could still do the root-only stuff, but then you could start a fuzzing > process with that flag set, knowing that the fuzzing process - and > it's children - are not able to do things). I don't think that fuzzing mechanisms is clever enough to distinguish which process (fuzz tests or _normal_ system binaries) is causing the unwanted result (e.g. shutting down the system). If administrator's proper operation (e.g. freezing a filesystem for maintenance purpose) caused a warning (e.g. khungtaskd complains that file write operation cannot be completed), fuzzing mechanisms (e.g. monitoring kernel messages printed to consoles) will consider it as "crash". Since who did "dangerous operation" is irrelevant, who can do "dangerous operation" (e.g. use of per-process flags) is irrelevant. Doing --- a/security/tomoyo/util.c +++ b/security/tomoyo/util.c @@ -1078,10 +1078,9 @@ bool tomoyo_domain_quota_is_ok(struct tomoyo_request_info *r) domain->flags[TOMOYO_DIF_QUOTA_WARNED] = true; /* r->granted = false; */ tomoyo_write_log(r, "%s", tomoyo_dif[TOMOYO_DIF_QUOTA_WARNED]); -#ifndef CONFIG_SECURITY_TOMOYO_INSECURE_BUILTIN_SETTING - pr_warn("WARNING: Domain '%s' has too many ACLs to hold. Stopped learning mode.\n", - domain->domainname->name); -#endif + if (current->do_not_emit_warning_string) + pr_warn("WARNING: Domain '%s' has too many ACLs to hold. Stopped learning mode.\n", + domain->domainname->name); } return false; } is pointless for syzkaller; syzkaller will treat as "crash" as soon as _normal_ system binaries hit this path. Use of build-time config option is simpler. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-04-18 15:09 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-13 6:33 [PATCH v3] Add kernel config option for tweaking kernel behavior Tetsuo Handa 2020-04-13 8:14 ` Greg Kroah-Hartman 2020-04-18 14:28 ` Tetsuo Handa 2020-04-18 14:39 ` Greg Kroah-Hartman 2020-04-18 15:08 ` Tetsuo Handa 2020-04-13 18:13 ` Linus Torvalds 2020-04-14 8:02 ` Tetsuo Handa 2020-04-15 0:05 ` Tetsuo Handa 2020-04-15 1:14 ` Linus Torvalds 2020-04-15 1:43 ` Steven Rostedt 2020-04-16 0:47 ` Tetsuo Handa
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).