linux-kernel - Re: [PATCH v3 net-next 10/24] net: dsa: Unset vlan

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, 16 Apr 2019 16:59:11 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>, vivien.didelot@...il.com,
        andrew@...n.ch, davem@...emloft.net
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        georg.waibel@...sor-technik.de
Subject: Re: [PATCH v3 net-next 10/24] net: dsa: Unset vlan_filtering when
 ports leave the bridge

On 12/04/2019 18:28, Vladimir Oltean wrote:
> When ports are standalone (after they left the bridge), they should have
> no VLAN filtering semantics (they should pass all traffic to the CPU).

The reset of the commit message is fine but this particular sentence 
sort of conflicts with the fact that we set NETIF_F_VLAN_RX_CTAG after 
my recent changes in order to support standalone ports + bridge ports w/ 
VLAN filtering on. What this feature flag means is that ingress VLAN 
filtering is active/supported.

On that particular topic this also means that for things like tcpdump to 
keep working on standalone ports while we have bridged ports w/ VLAN 
filtering turned on, we might have to re-configure how the switch 
performs ingress VLAN filtering checking when we have a standalone port 
in promiscuous mode. On BCM53xx we can achieve that by having the CPU 
port be part of all VLANs (there is a shorthand register for that 
purpose) and doing ingress VID checking + copy violated frames to CPU 
port. Food for thought...

> Currently this is not true for switchdev drivers, because the bridge
> "forgets" to unset that.
> 
> Normally one would think that doing this at the bridge layer would be a
> better idea, i.e. call br_vlan_filter_toggle() from br_del_if(), similar
> to how nbp_vlan_init() is called from br_add_if().
> 
> However what complicates that approach, and makes this one preferable,
> is the fact that for the bridge core, vlan_filtering is a per-bridge
> setting, whereas for switchdev/DSA it is per-port. Also there are
> switches where the setting is per the entire device, and unsetting
> vlan_filtering one by one, for each leaving port, would not be possible
> from the bridge core without a certain level of awareness. So do this in
> DSA and let drivers be unaware of it.
> 
> Signed-off-by: Vladimir Oltean <olteanv@...il.com>

Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
-- 
Florian