netdev - Re: [PATCH net-next,v5 0/9] netfilter: flowtable bridge and vlan enhancements

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] [day] [month] [year] [list]

Date:   Sat, 21 Nov 2020 12:58:40 +0100
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Alexander Lobakin <alobakin@...me>
Cc:     netfilter-devel@...r.kernel.org, davem@...emloft.net,
        netdev@...r.kernel.org, kuba@...nel.org, fw@...len.de,
        razor@...ckwall.org, jeremy@...zel.net, tobias@...dekranz.com
Subject: Re: [PATCH net-next,v5 0/9] netfilter: flowtable bridge and vlan
 enhancements

Hi,

On Fri, Nov 20, 2020 at 03:09:37PM +0000, Alexander Lobakin wrote:
> From: Pablo Neira Ayuso <pablo@...filter.org>
> Date: Fri, 20 Nov 2020 13:49:12 +0100
[...]
> > The following patchset augments the Netfilter flowtable fastpath to
> > support for network topologies that combine IP forwarding, bridge and
> > VLAN devices.
> 
> I'm curious if this new infra can be expanded later to shortcut other
> VLAN-like virtual netdevs e.g. DSA-like switch slaves.
> 
> I mean, usually we have port0...portX physical port representors
> and backing CPU port with ethX representor. When in comes to NAT,
> portX is set as destination. Flow offload calls dev_queue_xmit()
> on it, switch stack pushes CPU tag into the skb, change skb->dev
> to ethX and calls another dev_queue_xmit().
> 
> If we could (using the new .ndo_fill_forward_path()) tell Netfilter
> that our real dest is ethX and push the CPU tag via dev_hard_header(),
> this will omit one more dev_queue_xmit() and a bunch of indirect calls
> and checks.

If the XMIT_DIRECT path can be used for this with minimal changes,
that would be good.

> This might require some sort of "custom" or "private" cookies for
> N-Tuple though to separate flows from/to different switch ports (as
> it's done for VLAN: proto + VID).

Probably VLAN proto + VID in the tuple can be reused for this too.
Maybe add some extra information to tell if this is a VLAN or DSA
frame. It should be just one extra check for skb->protocol equals DSA.
Looks like very minimal changes to support for this.

> If so, I'd like to try to implement and publish that idea for reviews
> after this one lands nf-next.

Exploring new extensions is fine.

I received another email from someone else that would like to extend
this to support for PPPoE devices with PcEngines APU routers. In
general, adding more .ndo_fill_forward_path for more device types is
possible.