netdev - Re: [PATCH net-next] sandlan: Add the sandlan virtual network interface

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]

Date:   Thu, 17 Nov 2022 20:00:46 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Steve Williams <steve.williams@...cruise.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next] sandlan: Add the sandlan virtual network
 interface

On Wed, 16 Nov 2022 14:24:29 -0800 Steve Williams wrote:
> This is a virtual driver that is useful for testing network protocols
> or other complex networking without real ethernet hardware. Arbitrarily
> complex networks can be created and simulated by creating virtual network
> devices and assigning them to named broadcast domains, and all the usual
> ethernet-aware tools can operate on that network.
> 
> This is different from e.g. the tun/tap device driver in that it is not
> point-to-point. Virtual lans can be created that support broadcast,
> multicast, and unicast traffic. The sandlan nics are not tied to a
> process, but are instead persistent, have a mac address, can be queried
> by iproute2 tools, etc., as if they are physical ethernet devices. This
> provides a platform where, combined with netns support, distributed
> systems can be emulated. These nics can also be opened in raw mode, or
> even bound to other drivers that expect ethernet devices (vlans, etc),
> as a way to test and develop ethernet based network protocols.
> 
> A sandlan lan is not a tunnel. Packets are dispatched from a source
> nic to destination nics as would be done on a physical lan. If you
> want to create a nic to tunnel into an emulation, or to wrap packets
> up and forward them elsewhere, then you don't want sandlan, you want
> to use tun/tap or other tunneling support.

As a general rule we don't accept any test/emulation code upstream
unless it comes with some tests that actually use it.
We have had bad experience with people adding virtual interfaces and
features which then bit rot or become static checker fodder and we
don't know whether anyone is actually using them and how.

Is there something here that you can't achieve with appropriately
combined veths?