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: <50f74e7b-1b20-bf02-f5a8-b1667b834190@nvidia.com> Date: Fri, 11 Feb 2022 10:16:30 +0200 From: Nikolay Aleksandrov <nikolay@...dia.com> To: Felix Fietkau <nbd@....name>, <netdev@...r.kernel.org> Subject: Re: [RFC 1/2] net: bridge: add knob for filtering rx/tx BPDU packets on a port (resending, for some reason my first email didn't make it to the mailing list) On 10/02/2022 18:06, Felix Fietkau wrote: > > On 10.02.22 15:55, Nikolay Aleksandrov wrote: >> On 10/02/2022 16:24, Felix Fietkau wrote: >>> Some devices (e.g. wireless APs) can't have devices behind them be part of >>> a bridge topology with redundant links, due to address limitations. >>> Additionally, broadcast traffic on these devices is somewhat expensive, due to >>> the low data rate and wakeups of clients in powersave mode. >>> This knob can be used to ensure that BPDU packets are never sent or forwarded >>> to/from these devices >>> >>> Signed-off-by: Felix Fietkau <nbd@....name> >>> --- >>> include/linux/if_bridge.h | 1 + >>> include/uapi/linux/if_link.h | 1 + >>> net/bridge/br_forward.c | 5 +++++ >>> net/bridge/br_input.c | 2 ++ >>> net/bridge/br_netlink.c | 6 +++++- >>> net/bridge/br_stp_bpdu.c | 9 +++++++-- >>> net/core/rtnetlink.c | 4 +++- >>> 7 files changed, 24 insertions(+), 4 deletions(-) >>> >> >> Why can't netfilter or tc be used to filter these frames? > netfilter is slow as hell, and even adding a tc rule that has to look at all frames to check for useless BPDU packets costs a lot more CPU cycles than simply suppressing them at the source. > > - Felix You can use XDP, should be much faster. I don't want new tests in the fast path for something that is already solved and doesn't need anything bridge-specific. Tomorrow someone will try the same with some other packet type, sorry but absolutely unacceptable. Cheers, Nik
Powered by blists - more mailing lists