Message-ID: <67ca2e3467212_3c5672949f@willemb.c.googlers.com.notmuch>
Date: Thu, 06 Mar 2025 18:22:28 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Jakub Kicinski <kuba@...nel.org>, 
 Mina Almasry <almasrymina@...gle.com>
Cc: Pranjal Shrivastava <praan@...gle.com>, 
 Shivaji Kant <shivajikant@...gle.com>, 
 netdev@...r.kernel.org, 
 linux-kernel@...r.kernel.org, 
 linux-doc@...r.kernel.org, 
 kvm@...r.kernel.org, 
 virtualization@...ts.linux.dev, 
 linux-kselftest@...r.kernel.org, 
 Donald Hunter <donald.hunter@...il.com>, 
 "David S. Miller" <davem@...emloft.net>, 
 Eric Dumazet <edumazet@...gle.com>, 
 Paolo Abeni <pabeni@...hat.com>, 
 Simon Horman <horms@...nel.org>, 
 Jonathan Corbet <corbet@....net>, 
 Andrew Lunn <andrew+netdev@...n.ch>, 
 Jeroen de Borst <jeroendb@...gle.com>, 
 Harshitha Ramamurthy <hramamurthy@...gle.com>, 
 Kuniyuki Iwashima <kuniyu@...zon.com>, 
 Willem de Bruijn <willemb@...gle.com>, 
 David Ahern <dsahern@...nel.org>, 
 Neal Cardwell <ncardwell@...gle.com>, 
 "Michael S. Tsirkin" <mst@...hat.com>, 
 Jason Wang <jasowang@...hat.com>, 
 Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, 
 Eugenio Pérez <eperezma@...hat.com>, 
 Stefan Hajnoczi <stefanha@...hat.com>, 
 Stefano Garzarella <sgarzare@...hat.com>, 
 Shuah Khan <shuah@...nel.org>, 
 sdf@...ichev.me, 
 asml.silence@...il.com, 
 dw@...idwei.uk, 
 Jamal Hadi Salim <jhs@...atatu.com>, 
 Victor Nogueira <victor@...atatu.com>, 
 Pedro Tammela <pctammela@...atatu.com>, 
 Samiullah Khawaja <skhawaja@...gle.com>, 
 dvyukov@...gle.com, 
 nogikh@...gle.com
Subject: Re: [PATCH net-next v6 1/8] net: add get_netmem/put_netmem support

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.

Powered by blists - more mailing lists