Jakub Kicinski wrote: > On Thu, 6 Mar 2025 14:44:41 -0800 Mina Almasry wrote: > > > Meaning it doesn't currently do anything special, or you can't make it > > > do anything special with netdevsim? > > > > Meaning it currently doesn't do anything special with netdevsim. I > > imagine we may be able to create a specialized syzbot instance that > > loads netdevsim and starts fuzzing its APIs. However I'm told > > specialized syzbot instances are much less valuable than making the > > feature discoverable to existing syzbot instances, which is why our > > thoughts went to adding devmem/unreadable skb support to virtio or > > tun/tap. > > > > Do I surmise from your question you prefer a netdevsim-based approach? > > (and just curious maybe, why?) > > My exposure to syzbot is mostly as a consumer of reports, I thought > from looking at the repros that there's a way of teaching syzbot > how to perform more complex "ops", like a sequence of specific > writes. IIRC for netlink it does things like resolve family. > But not sure if it's true or how much of an exception adding such > things is. The standard way of increasing coverage is by teaching syzbot about new ABI extensions. Adding additional initialization, such as setting up a usdma buf, requires changing the repro scripts that it generates. Not sure where that code gen lives. But all .c repros consist of a small loop() that does the pertinent work, wrapped in a lot of initialization of the tun devices, tunnel devices, netns, etc, etc. > Here we'd need to guide syzbot towards a specific series of > sysfs writes, so that it creates the correctly configured netdevsim > instance with higher probability. > > Just explaining my thinking, not saying this is the way we should > necessarily go. > > > > We'll need to add queue API/page_pool/unreadable netmem support to > > > > one of the drivers qemu (syzbot) uses, and that should get syzbot > > > > fuzzing the control plane. > > > > > > > > To get syzbot to fuzz the data plane, I think we need to set up a > > > > special syzbot instance which configures udmabuf/rss/flow > > > > > > To be clear for Tx you don't need RSS and flow steering, Tx should > > > be trivial for any device driver which managers DMAs directly (not USB). > > > > Yes, we don't need queue API or page_pool support or header split > > either for that matter. TX fuzzing is definitely simpler. Maybe we can > > start with that. > > Adding support to virtio would be ideal, if syzbot already fuzzes it. > I was recently talking to David Wei about it for the Rx side, too, > so we can test io_uring ZC. But io_uring can only ZC user memory now. > I'm not sure what adding DEVMEM support to virtio would entail. By default syzbot uses a local tun device. At least all the reports that I have seen. That is why virtio_net_hdr_to_skb was such a frequent target. We also added tun IFF_NAPI and IFF_NAPI_FRAGS to get more coverage of those receive paths in syzbot. If expanding syzkaller to a devmem rx path, tun would be more first choice. But since devmem requires page_pool, queue API, etc., another virtual device that already has those may be an alternative, not sure.
