linux-kernel - Re: [PATCH net 2/2] selftests: net: bridge_vlan_aware: test untagged/8021p-tagged with and without PVID

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]

Message-ID: <aAuPYMhMECYMoNX8@shredder>
Date: Fri, 25 Apr 2025 16:34:24 +0300
From: Ido Schimmel <idosch@...dia.com>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: netdev@...r.kernel.org, Claudiu Manoil <claudiu.manoil@....com>,
	Alexandre Belloni <alexandre.belloni@...tlin.com>,
	UNGLinuxDriver@...rochip.com, Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>, Shuah Khan <shuah@...nel.org>,
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net 2/2] selftests: net: bridge_vlan_aware: test
 untagged/8021p-tagged with and without PVID

On Fri, Apr 25, 2025 at 01:37:34AM +0300, Vladimir Oltean wrote:
> Recent discussions around commit ad1afb003939 ("vlan_dev: VLAN 0 should
> be treated as "no vlan tag" (802.1p packet)") have sparked the question
> what happens with the DSA (and possibly other switchdev) data path when
> the bridge says that ports should have no PVID VLAN, but the 8021q
> module, as the result of a NETDEV_UP event, decides it should add VID 0
> to the RX filter of those bridge ports. Do those bridge ports receive
> packets tagged with VID 0 or not, now? We don't know, there is no test.
> 
> In the veth realm, this passes trivially, because veth is not VLAN
> filtering and this, the 8021q module lacks the instinct to add VID 0 in
> the first place.
> 
> In the realm of VLAN filtering NICs with no switchdev offload, this
> should also pass, because the VLAN groups of the software bridge are
> consulted, where it can clearly be seen that a PVID is missing, even
> though the packet was initially accepted by the NIC.
> 
> The test only poses a challenge for switchdev drivers, which usually
> have to program to hardware both VLANs from RX filtering, as well as
> from switchdev. Especially when a switchdev port joins a VLAN-aware
> bridge, it is unavoidable that it gains the NETIF_F_HW_VLAN_CTAG_FILTER
> feature, i.e. any 8021q uppers that the bridge port may have must also
> be committed to the RX filtering table of the interface. When a
> VLAN-tagged packet is physically received by the port, it is initially
> indistinguishable whether it will reach the bridge data path or the
> 8021q upper data path.
> 
> That is rather the final step of the new tests that we introduce.
> We need to build context up to that stage, which means the following:
> 
> - we need to test that 802.1p (VID 0) tagged traffic is received in the
>   first place (on bridge ports with a valid PVID). This is the "8021p"
>   test.
> 
> - we need to test that the usual paths of reaching a configuration with
>   no PVID on a bridge port are all covered and they all reach the same
>   state.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>

Reviewed-by: Ido Schimmel <idosch@...dia.com>
Tested-by: Ido Schimmel <idosch@...dia.com>