Hi Ted, On 2023-05-25 at 13:55:42 -0400, Theodore Ts'o wrote: > On Thu, May 25, 2023 at 04:15:01PM +1000, Dave Chinner wrote: > > Google's syzbot does this now, so your syzkaller bot should also be > > able to do it.... > > > > Please go and talk to the syzkaller authors to find out how they > > extract filesystem images from the reproducer, and any other > > information they've also been asked to provide for triage > > purposes. > > Pengfei, > > What is it that your syzkaller instance doing that Google's upstream > syzkaller instance is not doing? Google's syzkaller's team is been > very responsive at improving syzkaller's Web UI, including making it > easy to get artifacts from the syzkaller instance, requesting that > their bot to test a particular git tree or patch (since sometimes > reproducer doesn't easily reproduce on KVM, but easily reproduces in > their Google Cloud VM environment). > > So if there is some unique feature which you've added to your syzbot > instances, maybe you can contribute that change upstream, so that > everyone can benefit? From an upstream developer's perspective, it > also means that I can very easily take a look at the currently active > syzbot reports for a particular subsystem --- for example: > > https://syzkaller.appspot.com/upstream/s/ext4 > > ... and I can see how often a particular syzbot issue reproduces, and > it makes it easier for me to prioritize which syzbot report I should > work on next. If there is a discussion on a particular report, I can > get a link to that discussion on lore.kernel.org; and once a patch has > been submitted, there is an indication on the dashboard that there is > a PATCH associated with that particular report. > > For example, take a look at this report: > > https://syzkaller.appspot.com/bug?extid=e44749b6ba4d0434cd47 > > ... and look at the contents under the Discussion section; and then > open up the "Last patch testing requests" collapsible section. > > These are some of the reasons why using Google's instance of syzkaller > is a huge value add --- and quite frankly, it means that I will > prioritize looking at syzkaller reports on the syzkaller.appspot.com > dashboard, where I can easily prioritize which reports are most useful > for me to look at next, over those that you and others might forward > from some company's private syzkaller instance. It's just far more > productive for me as an upstream maintainer. > > Bottom line, having various companies run their own private instances > of syzkaller is much less useful for the upstream community. If Intel > feels that it's useful to run their own instance, maybe there's some > way you can work with Google syzkaller team so you don't have to do > that? > > Are there some improvements to the syzkaller code base Intel would be > willing to contribute to the upstream syzkaller code base at > https://github.com/google/syzkaller? Or is there some other reason > why Intel is running its own syzkaller instance? > Yes, I agree that we should work together to improve Syzkaller in case any coverage/feature is not supported by Syzkaller to ensure others can benefit from it. For example, I added IOMMUFD syscall description and user space SHSTK(shadow stack) tests for x86 platforms in syzkaller. Syzkaller is an unsupervised coverage-guided kernel fuzzer. According to my observation, some issues are platform dependent. Intel specific platforms could find some other different mainline kernel bugs by syzkaller tool which syzbot(https://syzkaller.appspot.com/upstream) doesn't find. And there are some special configurations like IOMMUFD, user space SHSTK (shadow stack) Intel cares about, for SHSTK, it needs HW support and qemu support also, we could cover some special situation to find more bugs. For example IOMMU related issues: Report: https://lore.kernel.org/all/ZBE1k040xAhIuTmq@xxxxxxxxxxxxxxxx/ Patch and veirfied: https://lore.kernel.org/linux-iommu/ZCfN0MSBxfYTm7kI@xxxxxxxxxxxxxxxx/ In order to solve these bugs, it makes sense for us to report the issues to Linux kernel community if no one has already reported them. Thanks! BR. > Cheers, > > - Ted
