Re: [PATCH v2] twist: allow converting pr_devel()/pr_debug() into snprintf()

[Andrey Konovalov <andreyknvl@google.com>]

On Mon, Jun 8, 2020 at 9:48 AM 'Dmitry Vyukov' via syzkaller
<syzkaller@googlegroups.com> wrote:
>
> On Fri, May 29, 2020 at 3:27 PM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> 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 syzkaller+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/CACT4Y%2BZ58Z8u1g8SBy-i1WxLMrdmXvggsLFAhfbLc8D%3DuffPyA%40mail.gmail.com.