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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 14 Feb 2020 13:25:18 -0500
From:   Vivien Didelot <vivien.didelot@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     netdev@...r.kernel.org, olteanv@...il.com, hkallweit1@...il.com,
        michal.vokac@...ft.com, Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net] net: dsa: Treat VLAN ID 0 as PVID untagged

Hi Florian,

On Wed, 12 Feb 2020 12:05:55 -0800, Florian Fainelli <f.fainelli@...il.com> wrote:
> VLAN ID 0 is special by all kinds and is really meant to be the default
> ingress and egress untagged VLAN. We were not configuring it that way
> and so we would be ingress untagged but egress tagged.
> 
> When our devices are interfaced with other link partners such as switch
> devices, the results would be entirely equipment dependent. Some
> switches are completely fine with accepting an egress tagged frame with
> VLAN ID 0 and would send their responses untagged, so everything works,
> but other devices are not so tolerant and would typically reject a VLAN
> ID 0 tagged frame.
> 
> Fixes: 061f6a505ac3 ("net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation")
> Signed-off-by: Florian Fainelli <f.fainelli@...il.com>
> ---
> Hi all,
> 
> After looking at all DSA drivers and how they implement port_vlan_add()
> I think this is the right change to do, but would appreciate if you
> could test this on your respective platforms to ensure this is not
> problematic.
> 
> Thank you
> 
> 
>  net/dsa/slave.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index 088c886e609e..d3a2782eb94d 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -1100,6 +1100,7 @@ static int dsa_slave_vlan_rx_add_vid(struct net_device *dev, __be16 proto,
>  {
>  	struct dsa_port *dp = dsa_slave_to_port(dev);
>  	struct bridge_vlan_info info;
> +	u16 flags = 0;
>  	int ret;
>  
>  	/* Check for a possible bridge VLAN entry now since there is no
> @@ -1118,7 +1119,13 @@ static int dsa_slave_vlan_rx_add_vid(struct net_device *dev, __be16 proto,
>  			return -EBUSY;
>  	}
>  
> -	ret = dsa_port_vid_add(dp, vid, 0);
> +	/* VLAN ID 0 is special and should be the default egress and ingress
> +	 * untagged VLAN, make sure it gets programmed as such.
> +	 */
> +	if (vid == 0)
> +		flags = BRIDGE_VLAN_INFO_PVID | BRIDGE_VLAN_INFO_UNTAGGED;
> +
> +	ret = dsa_port_vid_add(dp, vid, flags);
>  	if (ret)
>  		return ret;

If a frame tagged with VID 0 ingresses a Marvell port with 802.1Q enabled,
the VID assigned will be the port's default VID.

That being said, the hardware shouldn't prevent us from programming a port's
default VID as 0 or adding an entry for VID 0 in the VLAN table, but AFAICT
we are rejecting the latter for some reasons (it might have no effect, idk).

With this change we will be overriding the port's default VID with 0 in
addition to attempting to program a VLAN entry for the null VID (mv88e6xxx
would still return -EOPNOTSUPP at the moment for both anyway). Am I correct?


Thank you,

	Vivien

Powered by blists - more mailing lists