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: <20221010115731.qjji7bgt53rusvzf@skbuf>
Date:   Mon, 10 Oct 2022 11:57:31 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Sasha Levin <sashal@...nel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH AUTOSEL 6.0 12/77] net: mscc: ocelot: adjust forwarding
 domain for CPU ports in a LAG

On Sun, Oct 09, 2022 at 06:06:49PM -0400, Sasha Levin wrote:
> From: Vladimir Oltean <vladimir.oltean@....com>
> 
> [ Upstream commit 291ac1517af58670740528466ccebe3caefb9093 ]
> 
> Currently when we have 2 CPU ports configured for DSA tag_8021q mode and
> we put them in a LAG, a PGID dump looks like this:
> 
> PGID_SRC[0] = ports 4,
> PGID_SRC[1] = ports 4,
> PGID_SRC[2] = ports 4,
> PGID_SRC[3] = ports 4,
> PGID_SRC[4] = ports 0, 1, 2, 3, 4, 5,
> PGID_SRC[5] = no ports
> 
> (ports 0-3 are user ports, ports 4 and 5 are CPU ports)
> 
> There are 2 problems with the configuration above:
> 
> - user ports should enable forwarding towards both CPU ports, not just 4,
>   and the aggregation PGIDs should prune one CPU port or the other from
>   the destination port mask, based on a hash computed from packet headers.
> 
> - CPU ports should not be allowed to forward towards themselves and also
>   not towards other ports in the same LAG as themselves
> 
> The first problem requires fixing up the PGID_SRC of user ports, when
> ocelot_port_assigned_dsa_8021q_cpu_mask() is called. We need to say that
> when a user port is assigned to a tag_8021q CPU port and that port is in
> a LAG, it should forward towards all ports in that LAG.
> 
> The second problem requires fixing up the PGID_SRC of port 4, to remove
> ports 4 and 5 (in a LAG) from the allowed destinations.
> 
> After this change, the PGID source masks look as follows:
> 
> PGID_SRC[0] = ports 4, 5,
> PGID_SRC[1] = ports 4, 5,
> PGID_SRC[2] = ports 4, 5,
> PGID_SRC[3] = ports 4, 5,
> PGID_SRC[4] = ports 0, 1, 2, 3,
> PGID_SRC[5] = no ports
> 
> Note that PGID_SRC[5] still looks weird (it should say "0, 1, 2, 3" just
> like PGID_SRC[4] does), but I've tested forwarding through this CPU port
> and it doesn't seem like anything is affected (it appears that PGID_SRC[4]
> is being looked up on forwarding from the CPU, since both ports 4 and 5
> have logical port ID 4). The reason why it looks weird is because
> we've never called ocelot_port_assign_dsa_8021q_cpu() for any user port
> towards port 5 (all user ports are assigned to port 4 which is in a LAG
> with 5).
> 
> Since things aren't broken, I'm willing to leave it like that for now
> and just document the oddity.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
> Signed-off-by: Paolo Abeni <pabeni@...hat.com>
> Signed-off-by: Sasha Levin <sashal@...nel.org>
> ---

Not needed for stable kernels, please drop, thanks.

Powered by blists - more mailing lists