netdev - Re: [RFC 1/2] net: bridge: add knob for filtering rx/tx BPDU packets on a port

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:   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