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
| ||
|
Message-ID: <20220717125718.mj7b3j3jmltu6gm5@skbuf> Date: Sun, 17 Jul 2022 15:57:18 +0300 From: Vladimir Oltean <olteanv@...il.com> To: netdev@...io-technology.com Cc: Ido Schimmel <idosch@...dia.com>, davem@...emloft.net, kuba@...nel.org, netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>, Vivien Didelot <vivien.didelot@...il.com>, Florian Fainelli <f.fainelli@...il.com>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Jiri Pirko <jiri@...nulli.us>, Ivan Vecera <ivecera@...hat.com>, Roopa Prabhu <roopa@...dia.com>, Nikolay Aleksandrov <razor@...ckwall.org>, Shuah Khan <shuah@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, linux-kernel@...r.kernel.org, bridge@...ts.linux-foundation.org, linux-kselftest@...r.kernel.org Subject: Re: [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers On Sun, Jul 17, 2022 at 02:21:47PM +0200, netdev@...io-technology.com wrote: > On 2022-07-13 14:39, Ido Schimmel wrote: > > On Wed, Jul 13, 2022 at 09:09:58AM +0200, netdev@...io-technology.com > > wrote: > > > > > What are "Storm Prevention" and "zero-DPV" FDB entries? > > They are both FDB entries that at the HW level drops all packets having a > specific SA, thus using minimum resources. > (thus the name "Storm Prevention" aka, protection against DOS attacks. We > must remember that we operate with CPU based learning.) DPV means Destination Port Vector, and an ATU entry with a DPV of 0 essentially means a FDB entry pointing nowhere, so it will drop the packet. That's a slight problem with Hans' implementation, the bridge thinks that the locked FDB entry belongs to port X, but in reality it matches on all bridged ports (since it matches by FID). FID allocation in mv88e6xxx is slightly strange, all VLAN-unaware bridge ports, belonging to any bridge, share the same FID, so the FDB databases are not exactly isolated from each other.
Powered by blists - more mailing lists