netdev - Re: [PATCH v2 0/3] tun: Unify vnet implementation and fill full vnet header

More Web Proxy on the site http://driver.im/

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: <677fd3393b354_362bc129476@willemb.c.googlers.com.notmuch>
Date: Thu, 09 Jan 2025 08:46:33 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Akihiko Odaki <akihiko.odaki@...nix.com>, 
 Jonathan Corbet <corbet@....net>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>, 
 Jason Wang <jasowang@...hat.com>, 
 "David S. Miller" <davem@...emloft.net>, 
 Eric Dumazet <edumazet@...gle.com>, 
 Jakub Kicinski <kuba@...nel.org>, 
 Paolo Abeni <pabeni@...hat.com>, 
 "Michael S. Tsirkin" <mst@...hat.com>, 
 Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, 
 Shuah Khan <shuah@...nel.org>, 
 linux-doc@...r.kernel.org, 
 linux-kernel@...r.kernel.org, 
 netdev@...r.kernel.org, 
 kvm@...r.kernel.org, 
 virtualization@...ts.linux-foundation.org, 
 linux-kselftest@...r.kernel.org, 
 Yuri Benditovich <yuri.benditovich@...nix.com>, 
 Andrew Melnychenko <andrew@...nix.com>, 
 Stephen Hemminger <stephen@...workplumber.org>, 
 gur.stavi@...wei.com, 
 devel@...nix.com, 
 Akihiko Odaki <akihiko.odaki@...nix.com>
Subject: Re: [PATCH v2 0/3] tun: Unify vnet implementation and fill full vnet
 header

Akihiko Odaki wrote:
> When I implemented virtio's hash-related features to tun/tap [1],
> I found tun/tap does not fill the entire region reserved for the virtio
> header, leaving some uninitialized hole in the middle of the buffer
> after read()/recvmesg().
> 
> This series fills the uninitialized hole. More concretely, the
> num_buffers field will be initialized with 1, and the other fields will
> be inialized with 0. Setting the num_buffers field to 1 is mandated by
> virtio 1.0 [2].
> 
> The change to virtio header is preceded by another change that refactors
> tun and tap to unify their virtio-related code.
> 
> [1]: https://lore.kernel.org/r/20241008-rss-v5-0-f3cf68df005d@daynix.com
> [2]: https://lore.kernel.org/r/20241227084256-mutt-send-email-mst@kernel.org/
> 
> Signed-off-by: Akihiko Odaki <akihiko.odaki@...nix.com>
> ---
> Changes in v2:
> - Fixed num_buffers endian.
> - Link to v1: https://lore.kernel.org/r/20250108-tun-v1-0-67d784b34374@daynix.com
> 
> ---
> Akihiko Odaki (3):
>       tun: Unify vnet implementation
>       tun: Pad virtio header with zero
>       tun: Set num_buffers for virtio 1.0

Patches should explicitly to net or net-next.

In this case if the undefined data would be a bug, that would target
net. It sounds as if this is only relevant with the upcoming hash
changes, so then it too can target net-next. If needed at all.

The first patch is clearly net-next material.

I would prefer to work on that independent from the rest. I'm in
favor of deduplicating logic across tun/tap/pf_packet. Have taken a
stab, but haven't gotten to a concrete series. This indeed a valid
deduplication effort.

We have to make sure that the code is identical between tun and tap,
or where it isn't (due to one of the two having received a change to
such code, but the other not) explicitly note that in the commit
message. As then it is a behavioral change.

Anyway, let's send the undefined data, hash and dedup changes
independently. And preferably one after the other, rather than
having concurrent conversations across threads.