On Mon, Jun 8, 2020 at 9:48 AM 'Dmitry Vyukov' via syzkaller <[email protected]> wrote: > > On Fri, May 29, 2020 at 3:27 PM Tetsuo Handa > <[email protected]> wrote: > > > > 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. > > Hello Tetsuo, > > Yes, command line arguments are easily changeable. Please send pull > requests to syzkaller, if you want to change something. > > > > (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... > > I think we have some confusion between syzkaller and syzbot here. > syzkaller itself does not enforce/require any kernel configuration, > hardware nor use or not use of initramfs. In fact, qemu VM type > supports initramfs today. Or syzkaller can work with bare machines > where all setup is up to the user. > syzbot is just one deployment of syzkaller with a particular > configuration/hardware. > > If this feature is useful for any linux kernel fuzzing, then we need > to have a plan for all users and setups. > > And, yes, an additional context is kernel developers reproducing bugs. > Not all of them may be happy about any additional steps, nor will > follow them. > > Answering your question, syzkaller can do some sanity checking of the > provided machine/kernel and reject working with it. If you tell me > what exactly needs to be checked, I can think where this code should > go. > However, again, I am not sure if one is using, say, Android phones and > they don't envision use of initramfs, then what? > > For syzbot, the build happens here: > https://github.com/google/syzkaller/blob/7751efd04aebb07bc82b5c0e8eeaca07be1ae112/pkg/build/linux.go#L72 > I don't know if initramfs is supported with GCE machines and what > exactly is required. > > > > (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? > > Most likely it's possible.
FTR, there's https://github.com/google/syzkaller/issues/1611 filed for this. > > > (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? > > The CONFIG_DEBUG_INFO_BTF relates to build config. This can't be > solved during boot, right? So what is the relation? > > > (5) Anything else? > > Reading: > https://www.kernel.org/doc/html/latest/admin-guide/bootconfig.html#boot-kernel-with-a-boot-config > It seems that boot config is just a more complex way to provide > command line arguments. syzbot already supports command line > arguments, and it looks much simpler and no additional work required. > Why do we want to use boot config? > > Next quarter we will be additionally busy with interns, so I can't > promise any time availability for syzbot improvements. But pull > requests are welcome. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller/CACT4Y%2BZ58Z8u1g8SBy-i1WxLMrdmXvggsLFAhfbLc8D%3DuffPyA%40mail.gmail.com.
