Re: Debian kernel testing on syzbot
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.
> 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
Reply to: