netdev - Re: [PATCH net] net: dsa: Centralize validation of VLAN configuration

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20210316224711.hu3dnyepxvu4m2l5@skbuf>
Date:   Wed, 17 Mar 2021 00:47:11 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Tobias Waldekranz <tobias@...dekranz.com>
Cc:     davem@...emloft.net, kuba@...nel.org, andrew@...n.ch,
        vivien.didelot@...il.com, f.fainelli@...il.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH net] net: dsa: Centralize validation of VLAN configuration

On Tue, Mar 16, 2021 at 11:40:13PM +0100, Tobias Waldekranz wrote:
> > Actually, I think there is a bigger issue.
> > Sadly, I only put 2 and 2 together now, and I believe we are still not
> > dealing correctly with 8021q uppers of bridge ports with vlan_filtering 0.
> > The network stack's expectation is described here:
> > https://patchwork.kernel.org/project/netdevbpf/patch/20210221213355.1241450-12-olteanv@gmail.com/
> 
> So this is the setup Ido is describing, right?
> 
> br1
>   \
>  .100  br0
>     \  / \
>     swp0 swp1
> 
> > Basically the problem is in the way DSA drives the configuration of the
> > hardware port. When VLAN filtering is disabled, VLAN awareness is disabled,
> > too, and we make no effort to classify packets according to the VLAN ID,
> > and take a different forwarding decision in hardware based on that. So
> > the traffic corresponding to the 8021q upper gets forwarded, flooded to
> > ports it shouldn't go to.
> 
> I will try to put this in my own words to see if I understand: the
> problem with the setup above is the discrepancy between how the switch
> and how Linux would handle VID 100 tagged frames.
> 
> In a s/swp/eth/-scenario, br0 would never see those frames since they
> would be snooped by swp0.100, whereas the switch will gleefully forward
> them to swp1.

Yes, pretty much, you can see with bridged veth pairs that this is
exactly what happens, you can ping through their 8021q uppers even
though you cannot ping through the veth interfaces themselves (and of
course, you can ping through the bridge, but that is beside the point).

> $PROFANITY

+2