netdev - Re: [EXT] 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]

Message-ID: <20221121200212.77fb9a63@kernel.org>
Date:   Mon, 21 Nov 2022 20:02:12 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Steve Williams <steve.williams@...cruise.com>
Cc:     netdev@...r.kernel.org
Subject: Re: [EXT] Re: [PATCH net-next] sandlan: Add the sandlan virtual
 network interface

On Mon, 21 Nov 2022 18:59:11 -0800 Steve Williams wrote:
> > 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?  
> 
> I use the sandlan virtual interfaces to test my hanic driver, which I also just
> posted as a patch. The hanic driver implements redundant links and sets
> ethernet mac addresses, and also uses those mac addresses to infer streams
> for deduplication. The veth driver only creates pairs of nics, and it doesn't
> seem to support setting  the mac address

Understood, perhaps extending netdevsim to teach it to do packet
forwarding is an option then? I hope you'll understand that we can't
accept an extra harness driver for every protocol implementation we
accept. That is the short and the long of it.

> *Confidentiality Note:* We care about protecting our proprietary 
> information, confidential material, and trade secrets. This message may 
> contain some or all of those things. Cruise will suffer material harm if 
> anyone other than the intended recipient disseminates or takes any action 
> based on this message. If you have received this message (including any 
> attachments) in error, please delete it immediately and notify the sender 
> promptly.

You absolutely _must_ get rid of this privacy notice when posting
upstream.