netdev - Re: Port mirroring, v2 (RFC)

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:   Tue, 18 Jan 2022 10:30:17 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Alex Elder <elder@...aro.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Network Development <netdev@...r.kernel.org>,
        "bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: Port mirroring, v2 (RFC)

On Tue, 18 Jan 2022 11:37:05 -0600 Alex Elder wrote:
> I'm basically ready to go on this, either way (using a
> misc device, or--preferably--using a netdev).
> 
> I'm just trying to avoid getting that fully working,
> then learning when I submit patches that someone thinks
> it's the wrong way to go about it.
> 
> If a netdev is acceptable, my remaining issues are:
> - Whether/how to avoid having the device be treated
>    as if it needed support from the network stack
>    (i.e., as a "real" network interface, serving to
>    send and receive packets).
> - Similar, whether there are special configuration
>    options that should be used, given the device's
>    purpose.
> - What to call this functionality.  I'll avoid "mirror"
>    and will try to come up with something reasonable,
>    but suggestions are welcome.

I can't claim that my opinions on this sort of stuff are very stable
but I like Andrew's suggestion and I'd even say maybe just debugfs...

We try hard to prevent any abuse of netdevs for carrying what is not
real networking traffic and keep the semantics clear. netdevs are not
meant as an abstraction, they are more of an exception to the
"everything is a file" Unix rule.

Another thing that could possibly work is devlink traps and
DEVLINK_TRAP_ACTION_MIRROR, but again, not sure if we want to bend that
interface which has pretty nice and clear semantics to support a vendor
use case which is an aberration from our forwarding model in the
first place...

So I'd do something simple in debugfs and if anyone really cares about
the forwarding details put the real effort into modeling/controlling 
the forwarding with Linux.