netdev - [PATCH net-next 0/2] net: dsa: VLAN devices w/ filtering

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

Message-Id: <20190220223539.22106-1-f.fainelli@gmail.com>
Date:   Wed, 20 Feb 2019 14:35:37 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     netdev@...r.kernel.org
Cc:     Florian Fainelli <f.fainelli@...il.com>, andrew@...n.ch,
        vivien.didelot@...il.com, davem@...emloft.net, idosch@...lanox.com,
        jiri@...lanox.com, rmk+kernel@...linux.org.uk
Subject: [PATCH net-next 0/2] net: dsa: VLAN devices w/ filtering

Hi all,

This patch series supports having VLAN devices on top of DSA/switch
ports while the switch has VLAN filtering globally turned on (as is the
case with Broadcom switches). Whether the switch does global or per-port
VLAN filtering, having VLAN entries for these VLAN devices is
beneficial.

We take care of a few possibly problematic cases:

- adding a VLAN device while there is an existing VLAN entry created by
  a VLAN aware bridge. The entire bridge's VLAN database and not just
  the specific bridge port is being checked to be safe and conserative

- adding a bridge VLAN entry when there is an existing VLAN device
  created is also not possible because that would lead to the bridge
  being able to manipulate the VLAN device's VID/attributes under its feet

- enslaving a VLAN device into a VLAN aware bridge since that duplicates
  functionality already offered by the VLAN aware bridge

Here are the different test cases that were run to exercise this:

# Create a br0 device with gphy enslaved, verify we can still obtain
# a DHCP lease
ip addr flush dev gphy
ip link add dev br0 type bridge
echo 1 > /sys/class/net/br0/bridge/vlan_filtering
ip link set dev gphy master br0
udhcpc -i br0

# Create a VID 100 interface on top of rgmii_1, verify
# we can ping 192.168.100.1 (the peer)
vconfig add rgmii_1 100
ifconfig rgmii_1.100 192.168.100.10
ping -c 2 192.168.100.1

# Create a VID 42 interface on top of br0 and let it flow tagged
# through the bridge, verify we can ping 192.168.42.1 (the peer)
vconfig add br0 42
bridge vlan add vid 42 dev gphy
bridge vlan add vid 42 dev br0 self
ifconfig br0.42 192.168.42.2
ping -c 2 192.168.42.1

# Delete and re-create rgmii_1.100 and verify things still work
# with or without VLAN filtering applied:
ip link del rgmii_1.100
vconfig add rgmii_1 100
ifconfig rgmii_1.100 192.168.100.10
ping -c 2 192.168.100.1
echo 0 > /sys/class/net/br0/bridge/vlan_filtering
ping -c 2 192.168.100.1

# Delete and attempt to create collision scenarios
ip link del rgmii_1.100
echo 1 > /sys/class/net/br0/bridge/vlan_filtering

# VLAN ID 100 is already claimed by rgmii_1.100
vconfig add rgmii_1 100
brctl addif br0 rgmii_1
# Adding VLAN 100 to rgmii_1 fails since rgmii_1.100 exists
bridge vlan add vid 100 dev rgmii_1

vconfig rem rgmii_1.100
# Adding VLAN 100 to rgmii_1 works since rgmii_1.100 does not exist
bridge vlan add vid 100 dev rgmii_1
# But this fails since we already have a VID with the bridge
vconfig add rgmii_1 100

# Delete and re-create the interface and try to make it enslaved
bridge vlan del vid 100 dev rgmii_1
vconfig add rgmii_1 100
# This fails since the bridge is VLAN aware
brctl addif br0 rgmii_1.100

Florian Fainelli (2):
  net: dsa: Deny enslaving VLAN devices into VLAN aware bridge
  net: dsa: Add ndo_vlan_rx_{add,kill}_vid implementation

 net/dsa/port.c   |  12 ++++--
 net/dsa/slave.c  | 110 +++++++++++++++++++++++++++++++++++++++++++++--
 net/dsa/switch.c |  42 ++++++++++++++++++
 3 files changed, 157 insertions(+), 7 deletions(-)

-- 
2.17.1