netdev - Correct PVID behavior with bridge's VLAN filtering on/off?

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: <61ecaa9f-f1ba-f79e-1d8b-4ec2eba5dc11@gmail.com>
Date:   Tue, 11 Dec 2018 11:48:21 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     netdev@...r.kernel.org, roopa@...ulusnetworks.com,
        nikolay@...ulusnetworks.com, bridge@...ts.linux-foundation.org,
        jiri@...lanox.com, idosch@...lanox.com
Cc:     andrew@...n.ch, vivien.didelot@...il.com
Subject: Correct PVID behavior with bridge's VLAN filtering on/off?

Hi Nikolay, Roopa, Jiri, Ido,

When a bridge has vlan_filtering=0 and notifies a switch driver through
HOST_OBJ_MDB about MC addresses that the CPU/management port is
interested in getting MC traffic for, I am seeing that the mdb->vid is
set to 0 because br_allowed_ingress() checks for BROPT_VLAN_ENABLED
which is now disabled and so we never populated *vid to anything but 0
because the caller: br_handle_frame_finish() zeroed it out.

This creates a problem with the b53 DSA switch driver because in order
to match the bridge's default_pvid, we did program the switch's "default
tag" to be 1, which gets used for all untagged frames that ingress the
switch (which AFAICT is correct behavior for PVID).

Despite having turned off VLAN filtering in the switch such that it does
allow ingress of packets with a VID that is not present in the VLAN
table (violation), Multicast addresses do behave differently and we
really must be strictly matching the programmed PVID in order for MC
frames to ingress the switch even with VLAN filtering turned off.

So with all that being written, should the bridge still be sending MDB
notifications and use the bridge's default_pvid even with
vlan_filtering=0? And if we did that, what use case could we be possibly
breaking?

Let me know if this is not clear so I can provide mode details.

Thank you very much.
-- 
Florian