netdev - Re: [PATCH net] virtio-net: drop the multi-buffer XDP packet in zerocopy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250605074810.2b3b2637@kernel.org>
Date: Thu, 5 Jun 2025 07:48:10 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Bui Quang Minh <minhquangbui99@...il.com>
Cc: Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, "Michael S.
 Tsirkin" <mst@...hat.com>, Jason Wang <jasowang@...hat.com>, Xuan Zhuo
 <xuanzhuo@...ux.alibaba.com>, Eugenio Pérez
 <eperezma@...hat.com>, Andrew Lunn <andrew+netdev@...n.ch>, "David S.
 Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Alexei
 Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 Jesper Dangaard Brouer <hawk@...nel.org>, John Fastabend
 <john.fastabend@...il.com>, virtualization@...ts.linux.dev,
 linux-kernel@...r.kernel.org, bpf@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH net] virtio-net: drop the multi-buffer XDP packet in
 zerocopy

On Thu, 5 Jun 2025 21:33:26 +0700 Bui Quang Minh wrote:
> On 6/5/25 18:03, Paolo Abeni wrote:
> > On 6/3/25 5:06 PM, Bui Quang Minh wrote:  
> >> In virtio-net, we have not yet supported multi-buffer XDP packet in
> >> zerocopy mode when there is a binding XDP program. However, in that
> >> case, when receiving multi-buffer XDP packet, we skip the XDP program
> >> and return XDP_PASS. As a result, the packet is passed to normal network
> >> stack which is an incorrect behavior.  
> > Why? AFAICS the multi-buffer mode depends on features negotiation, which
> > is not controlled by the VM user.
> >
> > Let's suppose the user wants to attach an XDP program to do some per
> > packet stats accounting. That suddenly would cause drop packets
> > depending on conditions not controlled by the (guest) user. It looks
> > wrong to me.  
> 
> But currently, if a multi-buffer packet arrives, it will not go through 
> XDP program so it doesn't increase the stats but still goes to network 
> stack. So I think it's not a correct behavior.

Sounds fair, but at a glance the normal XDP path seems to be trying to
linearize the frame. Can we not try to flatten the frame here?
If it's simply to long for the chunk size that's a frame length error,
right?