netdev - Re: [EXT] Re: [PATCH net-next] net/hanic: Add the hanic network interface for high availability links

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:   Wed, 23 Nov 2022 16:26:14 +0200
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Steve Williams <steve.williams@...cruise.com>
Cc:     Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        vinicius.gomes@...el.com, xiaoliang.yang_1@....com,
        Jiri Pirko <jiri@...nulli.us>, Andrew Lunn <andrew@...n.ch>
Subject: Re: [EXT] Re: [PATCH net-next] net/hanic: Add the hanic network
 interface for high availability links

On Tue, Nov 22, 2022 at 12:51:53PM -0800, Steve Williams wrote:
> This driver provides a way for outbound traffic to be tagged and duplicated out
> multiple ports, and inbound R-TAG'ed packets to be deduplicated.

> Hanic tries to make the R-TAG handling transparent,

> Generic filtering and/or dynamic stream identification methods just seemed
> out of scope for this driver. Certainly out of scope for our needs.

> Yes, hanic implements a practical subset of the standard, and I try to be
> clear about that in the documentation.

I'm back with a more intelligent question, after looking a bit at the
code and at the problem it tries to solve.

The question is: why don't you create a tap interface, and a user space
program which is given the physical ports and tap interface as command
line arguments, and does the following:

- on reception from physical interfaces, handles 802.1CB traffic from
  physical ports, eliminates the duplicates and pops the R-TAG, then
  sends the packets to the tap interface
- handles packets transmitted to the tap, splits them and pushes
  whatever R-TAG is needed, then forwards them to the physical network
  interfaces

Then your Cruise 802.1CB endpoint solution becomes a user space handler
for a tap interface. To users of your solution, it's the same thing,
except they open their socket on a tap interface and not on a hanic
interface.

Reworded, why must the hanic functionality to be in the kernel?

Thank you.