Re: Debian kernel testing on syzbot
Hi!
On Wed, Jul 5, 2023 at 7:48 PM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Wed, 5 Jul 2023 at 08:53, Bo YU <tsu.yubo@gmail.com> wrote:
> > Hi
> >
> > On Wed, Jul 5, 2023 at 12:24 PM Dmitry Vyukov <dvyukov@google.com> wrote:
> > >
> > > On Wed, 28 Jun 2023 at 10:26, Dmitry Vyukov <dvyukov@google.com> wrote:
> > > > > Hello,
> > > > >
> > > > > Our team works on syzkaller/syzbot kernel fuzzer:
> > > > > https://github.com/google/syzkaller
> > > > > https://github.com/google/syzkaller/blob/master/docs/syzbot.md
> > > > >
> > > > > Currently we test the upstream kernel and recent LTS releases:
> > > > > https://syzkaller.appspot.com/upstream
> > > > > https://syzkaller.appspot.com/linux-6.1
> > > > > https://syzkaller.appspot.com/linux-5.15
> > > > > and report bugs to upstream developers:
> > > > > https://groups.google.com/g/syzkaller-bugs
> > > > >
> > > > > Due to Debian's relevance as one of the most widely used Linux
> > > > > distributions, we plan to test the Debian kernel as well.
> > > > >
> > > > > We were thinking about testing the "testing" release only initially.
> > > > > Or do you have other suggestions here?
> > > > >
> > > > > Do you want bugs to be reported privately first (to some closed
> > > > > mailing list) with some embargo? Or do we make them public (visible on
> > > > > syzbot dashboard) right away as we do for upstream/LTS?
> > > >
> > > > +Ben, you were pointed out as the person to provide "the official" response :)
> > > >
> > > > To clarify: we are not asking nor imply that anybody will actually act
> > > > in any way on the reported bugs. I mean anybody is welcome to, but
> > > > don't have to.
> > > > We can also just create a public web dashboard (+new opt-in mailing
> > > > list), if that's what we agree on here.
> > > >
> > > > And if there is an active interest in acting on the reports, we can
> > > > also test the unstable release (that's the better place to fix,
> > > > right).
> > >
> > > Ok, we will probably proceed with testing with no notifications for now.
> > >
> > Sorry, I'm sorry that I suddenly ran into this topic.
> > Personally, I think the sid(unstable) kernel is more appropriate for syzkaller.
> > Unstable by itself means unstable, if we have any issue we can fix it quickly.
> > Testing needs to be migrated from sid, which may cast a long time. In addition,
> > it is closer to upstream.
>
> Hi Bo,
>
> Thanks for your reply.
> If there will be active interest in looking at the report and fixing
> them, then we can set up unstable testing as well.
>
Thanks. But I am not a member of kernel team(just a kernel newbie) and
please follow your initial decision. Personally, I'm probably more concerned
about the bugs in the RISC-V kernel, so this may add to the burden of
the kernel team.
>
> > BTW, as a Debian RISC-V porter, I am wondering the syzkaller if is arch-indep
> > or not. You know Debian supports many architectures. If sure, I hope syzkaller
> > can support Debian/riscv64(yeah, it is in sid now, but it will be
> > entered into testing
> > soon).
>
> Per se syzkaller is completely arch-independent.
> It may lack descriptions for some arch-specific kernel interfaces
> (like arch_prctl's, arch-specific KVM ioctl's, etc). But there are
> usually few of them.
>
> However, on our testing infra we can test riscv only using qemu tcg
> emulation, which is extremely slow. So the riscv instance we have just
> mostly rediscovers and traps on arch-independent bugs that all other
> faster instances find much easier.
> Here is the list of bugs currently happening on the riscv instance:
> https://syzkaller.appspot.com/upstream?manager=ci-qemu2-riscv64
> And here is list of bugs that happens _only_ on riscv instance and not
> on any other one:
> https://syzkaller.appspot.com/upstream?only_manager=ci-qemu2-riscv64
Thank you very much for this valuable information which is what I was
looking for, thanks! I hope I can do something for it.
BR,
Bo
Reply to: