netdev - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 12 Dec 2018 11:02:38 +0200
From:   Ido Schimmel <idosch@...sch.org>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev@...r.kernel.org, roopa@...ulusnetworks.com,
        nikolay@...ulusnetworks.com, bridge@...ts.linux-foundation.org,
        jiri@...lanox.com, idosch@...lanox.com, andrew@...n.ch,
        vivien.didelot@...il.com
Subject: Re: Correct PVID behavior with bridge's VLAN filtering on/off?

On Tue, Dec 11, 2018 at 11:48:21AM -0800, Florian Fainelli wrote:
> 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.

s/br_handle_frame_finish()/br_dev_xmit()/ ? Since you're talking about
HOST_OBJ_MDB

> 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).

Not sure I'm following. If bridge is not VLAN-aware, then where do you
see 'default_pvid' being used?

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

I think you need to provide more details about the device you're working
with. I can explain what we're doing in mlxsw for reference.

When you use a VLAN-unaware bridge w/o VLAN devices, we make sure all
untagged packets get tagged with some arbitrary VLAN (now 1, soon 4095).
You never see this VLAN on the wire, since we remove it before sending
the packets. It is only used because all packets in the ASIC must be
tagged.

After we have a VLAN we classify the packet to a FID (bridge) and it
does {FID,DMAC} lookup in the FDB (MDB).

IIUC, your problem is that you also need to tag all the packets (you
used '1', can be something else), but then you program the MDB entry
according to the VLAN passed in the notification ('0') and not use
('1'). We completely ignore the VID in this case and use the FID which
we lookup based on the ifindex of the bridge.