netdev - Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: fix vlan setup

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:   Tue, 18 Feb 2020 14:09:07 -0500
From:   Vivien Didelot <vivien.didelot@...il.com>
To:     Russell King <rmk+kernel@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Ido Schimmel <idosch@...sch.org>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH net-next 3/3] net: dsa: mv88e6xxx: fix vlan setup

Hi Russell,

On Tue, 18 Feb 2020 11:46:20 +0000, Russell King <rmk+kernel@...linux.org.uk> wrote:
> DSA assumes that a bridge which has vlan filtering disabled is not
> vlan aware, and ignores all vlan configuration. However, the kernel
> software bridge code allows configuration in this state.
> 
> This causes the kernel's idea of the bridge vlan state and the
> hardware state to disagree, so "bridge vlan show" indicates a correct
> configuration but the hardware lacks all configuration. Even worse,
> enabling vlan filtering on a DSA bridge immediately blocks all traffic
> which, given the output of "bridge vlan show", is very confusing.
> 
> Provide an option that drivers can set to indicate they want to receive
> vlan configuration even when vlan filtering is disabled. This is safe
> for Marvell DSA bridges, which do not look up ingress traffic in the
> VTU if the port is in 8021Q disabled state. Whether this change is
> suitable for all DSA bridges is not known.
> 
> Signed-off-by: Russell King <rmk+kernel@...linux.org.uk>
> ---
>  drivers/net/dsa/mv88e6xxx/chip.c |  1 +
>  include/net/dsa.h                |  1 +
>  net/dsa/slave.c                  | 12 ++++++++----
>  3 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index 629eb7bbbb23..e656e571ef7d 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -2934,6 +2934,7 @@ static int mv88e6xxx_setup(struct dsa_switch *ds)
>  
>  	chip->ds = ds;
>  	ds->slave_mii_bus = mv88e6xxx_default_mdio_bus(chip);
> +	ds->vlan_bridge_vtu = true;
>  
>  	mv88e6xxx_reg_lock(chip);
>  
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> index 63495e3443ac..d3a826646e8e 100644
> --- a/include/net/dsa.h
> +++ b/include/net/dsa.h
> @@ -273,6 +273,7 @@ struct dsa_switch {
>  	 * settings on ports if not hardware-supported
>  	 */
>  	bool			vlan_filtering_is_global;
> +	bool			vlan_bridge_vtu;
>  
>  	/* In case vlan_filtering_is_global is set, the VLAN awareness state
>  	 * should be retrieved from here and not from the per-port settings.
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index 088c886e609e..534d511b349e 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -318,7 +318,8 @@ static int dsa_slave_vlan_add(struct net_device *dev,
>  	if (obj->orig_dev != dev)
>  		return -EOPNOTSUPP;
>  
> -	if (dp->bridge_dev && !br_vlan_enabled(dp->bridge_dev))
> +	if (dp->bridge_dev && !dp->ds->vlan_bridge_vtu &&
> +	    !br_vlan_enabled(dp->bridge_dev))
>  		return 0;
>  
>  	vlan = *SWITCHDEV_OBJ_PORT_VLAN(obj);
> @@ -385,7 +386,8 @@ static int dsa_slave_vlan_del(struct net_device *dev,
>  	if (obj->orig_dev != dev)
>  		return -EOPNOTSUPP;
>  
> -	if (dp->bridge_dev && !br_vlan_enabled(dp->bridge_dev))
> +	if (dp->bridge_dev && !dp->ds->vlan_bridge_vtu &&
> +	    !br_vlan_enabled(dp->bridge_dev))
>  		return 0;
>  
>  	/* Do not deprogram the CPU port as it may be shared with other user
> @@ -1106,7 +1108,8 @@ static int dsa_slave_vlan_rx_add_vid(struct net_device *dev, __be16 proto,
>  	 * need to emulate the switchdev prepare + commit phase.
>  	 */
>  	if (dp->bridge_dev) {
> -		if (!br_vlan_enabled(dp->bridge_dev))
> +		if (!dp->ds->vlan_bridge_vtu &&
> +		    !br_vlan_enabled(dp->bridge_dev))
>  			return 0;
>  
>  		/* br_vlan_get_info() returns -EINVAL or -ENOENT if the
> @@ -1140,7 +1143,8 @@ static int dsa_slave_vlan_rx_kill_vid(struct net_device *dev, __be16 proto,
>  	 * need to emulate the switchdev prepare + commit phase.
>  	 */
>  	if (dp->bridge_dev) {
> -		if (!br_vlan_enabled(dp->bridge_dev))
> +		if (!dp->ds->vlan_bridge_vtu &&
> +		    !br_vlan_enabled(dp->bridge_dev))
>  			return 0;
>  
>  		/* br_vlan_get_info() returns -EINVAL or -ENOENT if the

It is confusing to add a Marvell specific term (VTU) in the generic dsa_switch
structure to bypass the fact that VLAN configuration in hardware was already
bypassed for some reasons until vlan filtering is turned on. As you said,
simply offloading the VLAN configuration in hardware and only turning the
ports' 802.1Q mode to Secure once vlan_filtering is flipped to 1 should work
in theory for both VLAN filtering aware and unaware scenarios, but this was
causing problems if I'm not mistaken, I'll try to dig this out.

In the meantime, does the issue you're trying to solve here happens if you
create a vlan-filtering aware bridge in the first place, before any VLAN
configuration? i.e.:

    # ip link add name br0 type bridge vlan_filtering 1
    # ip link set master br0 dev lan1 up
    # bridge vlan add ...


Thank you,
Vivien