[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <38df9737-3c04-dca2-0df4-115a9c1634e5@i-love.sakura.ne.jp>
Date: Fri, 29 May 2020 22:26:48 +0900
From: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To: Dmitry Vyukov <dvyukov@...gle.com>,
syzkaller <syzkaller@...glegroups.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Petr Mladek <pmladek@...e.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Ondrej Mosnacek <omosnace@...hat.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v2] twist: allow converting pr_devel()/pr_debug() into
snprintf()
Hello, Dmitry.
Linus is asking me to avoid build-time switching based on kernel config options,
and is suggesting me to use boot-time switching based on boot-config file feature
(which is available since 5.6). I have several concerns about use of boot-config file
feature in syzkaller.
(1) To use boot-config file, syzkaller will need to add "bootconfig" option
to the kernel command line. This will be doable by patching
https://github.com/google/syzkaller/tree/master/dashboard/config/ *.cmdline
files.
(2) The boot-config file is embedded into initramfs file. Since syzkaller builds
kernels with almost-allyesconfig, booting syzkaller kernels do not require
initramfs for loading kernel modules needed for mounting the root partition.
In fact, according to "unexpected kernel reboot" report which contains boot messages,
I can't find "Unpacking initramfs..." message. It seems that syzkaller kernels do not
use initramfs file.
Is it possible for syzkaller to enforce performing steps for creating an initramfs,
embedding the boot-config file
( https://www.kernel.org/doc/html/latest/admin-guide/bootconfig.html#boot-kernel-with-a-boot-config),
and loading that initramfs whenever booting the syzkaller kernels?
By the way, I do worry that people forget to perform these steps when they do
their tests without asking syzbot...
(3) Since syzkaller keeps track of "kernel tree", "commit of the kernel tree", and
"commit of the syzkaller tree" in order to guarantee reproducibility, it would be
possible to identify the "your-config" file used for tools/bootconfig/bootconfig
command. But since "#syz test" command currently accepts only "kernel tree" and
"commit of the kernel tree" arguments, we might fail to use intended "your-config"
file when doing reproducibility test. Can syzbot solve this concern?
(4) Of course, "your-config" file would not change so frequently, but "#syz test" command
relies on external file in "syzkaller tree" makes it impossible to try different
configuration when I have to ask syzbot to test. (Since I don't have hardware which
syzbot is reporting problems, I have to ask syzbot when I can't reproduce the problem
in my environment.)
https://syzkaller.appspot.com/text?tag=Patch&x=135f254a100000 is an example of
need to enforce CONFIG_DEBUG_INFO_BTF=n in order to workaround build failure during
"#syz test" command. If we bring "which twist options should be enabled" to an external
boot-config file, I can't ask syzbot to try different twist options (except directly
patching the kernel source which handles "which twist options should be enabled").
Can syzbot solve this concern?
(5) Anything else?
Powered by blists - more mailing lists