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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f02ad768-2c8e-c8ed-e5f6-6ee79bf97c06@linaro.org>
Date:   Tue, 18 Jan 2022 12:33:43 -0600
From:   Alex Elder <elder@...aro.org>
To:     Jakub Kicinski <kuba@...nel.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 1/18/22 12:30 PM, Jakub Kicinski wrote:
> 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.

This is nice, clear guidance.

I'm going to work through that design and will send one
more RFC as my proposal.  It'll be somewhat short...

Thank you very much!

					-Alex