From: Johannes Nixdorf <jnixdorf-oss@avm.de>
To: "David S. Miller" <davem@davemloft.net>,
Andrew Lunn <andrew@lunn.ch>, David Ahern <dsahern@gmail.com>,
Eric Dumazet <edumazet@google.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Ido Schimmel <idosch@nvidia.com>,
Jakub Kicinski <kuba@kernel.org>,
Nikolay Aleksandrov <razor@blackwall.org>,
Oleksij Rempel <linux@rempel-privat.de>,
Paolo Abeni <pabeni@redhat.com>, Roopa Prabhu <roopa@nvidia.com>,
Shuah Khan <shuah@kernel.org>,
Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
Johannes Nixdorf <jnixdorf-oss@avm.de>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: [Bridge] [PATCH net-next v5 0/5] bridge: Add a limit on learned FDB entries
Date: Mon, 16 Oct 2023 15:27:19 +0200 [thread overview]
Message-ID: <20231016-fdb_limit-v5-0-32cddff87758@avm.de> (raw)
Introduce a limit on the amount of learned FDB entries on a bridge,
configured by netlink with a build time default on bridge creation in
the kernel config.
For backwards compatibility the kernel config default is disabling the
limit (0).
Without any limit a malicious actor may OOM a kernel by spamming packets
with changing MAC addresses on their bridge port, so allow the bridge
creator to limit the number of entries.
Currently the manual entries are identified by the bridge flags
BR_FDB_LOCAL or BR_FDB_ADDED_BY_USER, atomically bundled under the new
flag BR_FDB_DYNAMIC_LEARNED. This means the limit also applies to
entries created with BR_FDB_ADDED_BY_EXT_LEARN but none of BR_FDB_LOCAL
or BR_FDB_ADDED_BY_USER, e.g. ones added by SWITCHDEV_FDB_ADD_TO_BRIDGE.
Link to the corresponding iproute2 changes:
https://lore.kernel.org/r/20230919-fdb_limit-v4-1-b4d2dc4df30f@avm.de
Signed-off-by: Johannes Nixdorf <jnixdorf-oss@avm.de>
---
Changes in v5:
- Set IFLA_BR_FDB_N_LEARNED to NLA_REJECT (from review)
- Moved the strict_start_type-commit after the netlink change, used
the new attribute. (from review)
- Dropped the new build time config option. (from review)
- Link to v4: https://lore.kernel.org/r/20230919-fdb_limit-v4-0-39f0293807b8@avm.de
Changes in v4:
- Added the new test to the Makefile. (from review)
- Removed _entries from the names. (from iproute2 review, in some places
only for consistency)
- Wrapped the lines at 80 chars, except when longer lines are consistent
with neighbouring code. (from review)
- Fixed a race in fdb_delete. (from review)
- Link to v3: https://lore.kernel.org/r/20230905-fdb_limit-v3-0-7597cd500a82@avm.de
Changes in v3:
- Fixed the flags for fdb_create in fdb_add_entry to use
BIT(...). Previously we passed garbage. (from review)
- Set strict_start_type for br_policy. (from review)
- Split out the combined accounting and limit patch, and the netlink
patch from the combined patch in v2. (from review)
- Count atomically, remove the newly introduced lock. (from review)
- Added the new attributes to br_policy. (from review)
- Added a selftest for the new feature. (from review)
- Link to v2: https://lore.kernel.org/netdev/20230619071444.14625-1-jnixdorf-oss@avm.de/
Changes in v2:
- Added BR_FDB_ADDED_BY_USER earlier in fdb_add_entry to ensure the
limit is not applied.
- Do not initialize fdb_*_entries to 0. (from review)
- Do not skip decrementing on 0. (from review)
- Moved the counters to a conditional hole in struct net_bridge to
avoid growing the struct. (from review, it still grows the struct as
there are 2 32-bit values)
- Add IFLA_BR_FDB_CUR_LEARNED_ENTRIES (from review)
- Fix br_get_size() with the added attributes.
- Only limit learned entries, rename to
*_(CUR|MAX)_LEARNED_ENTRIES. (from review)
- Added a default limit in Kconfig. (deemed acceptable in review
comments, helps with embedded use-cases where a special purpose kernel
is built anyways)
- Added an iproute2 patch for easier testing.
- Link to v1: https://lore.kernel.org/netdev/20230515085046.4457-1-jnixdorf-oss@avm.de/
Obsolete v1 review comments:
- Return better errors to users: Due to limiting the limit to
automatically created entries, netlink fdb add requests and changing
bridge ports are never rejected, so they do not yet need a more
friendly error returned.
---
Johannes Nixdorf (5):
net: bridge: Set BR_FDB_ADDED_BY_USER early in fdb_add_entry
net: bridge: Track and limit dynamically learned FDB entries
net: bridge: Add netlink knobs for number / max learned FDB entries
net: bridge: Set strict_start_type for br_policy
selftests: forwarding: bridge_fdb_learning_limit: Add a new selftest
include/uapi/linux/if_link.h | 2 +
net/bridge/br_fdb.c | 42 ++-
net/bridge/br_netlink.c | 17 +-
net/bridge/br_private.h | 4 +
tools/testing/selftests/net/forwarding/Makefile | 3 +-
.../net/forwarding/bridge_fdb_learning_limit.sh | 283 +++++++++++++++++++++
6 files changed, 344 insertions(+), 7 deletions(-)
---
base-commit: 58720809f52779dc0f08e53e54b014209d13eebb
change-id: 20230904-fdb_limit-fae5bbf16c88
Best regards,
--
Johannes Nixdorf <jnixdorf-oss@avm.de>
next reply other threads:[~2023-10-16 13:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-16 13:27 Johannes Nixdorf [this message]
2023-10-16 13:27 ` [Bridge] [PATCH net-next v5 1/5] net: bridge: Set BR_FDB_ADDED_BY_USER early in fdb_add_entry Johannes Nixdorf
2023-10-16 13:27 ` [Bridge] [PATCH net-next v5 2/5] net: bridge: Track and limit dynamically learned FDB entries Johannes Nixdorf
2023-10-16 13:27 ` [Bridge] [PATCH net-next v5 3/5] net: bridge: Add netlink knobs for number / max " Johannes Nixdorf
2023-10-17 9:31 ` Nikolay Aleksandrov
2023-10-17 11:06 ` Ido Schimmel
2023-10-16 13:27 ` [Bridge] [PATCH net-next v5 4/5] net: bridge: Set strict_start_type for br_policy Johannes Nixdorf
2023-10-17 9:32 ` Nikolay Aleksandrov
2023-10-17 11:06 ` Ido Schimmel
2023-10-16 13:27 ` [Bridge] [PATCH net-next v5 5/5] selftests: forwarding: bridge_fdb_learning_limit: Add a new selftest Johannes Nixdorf
2023-10-18 1:00 ` [Bridge] [PATCH net-next v5 0/5] bridge: Add a limit on learned FDB entries patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231016-fdb_limit-v5-0-32cddff87758@avm.de \
--to=jnixdorf-oss@avm.de \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=idosch@nvidia.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux@rempel-privat.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.com \
--cc=shuah@kernel.org \
--cc=vladimir.oltean@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox