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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ