From: Ido Schimmel <idosch@idosch.org>
To: Johannes Nixdorf <jnixdorf-oss@avm.de>
Cc: Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
bridge@lists.linux-foundation.org,
Ido Schimmel <idosch@nvidia.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
Roopa Prabhu <roopa@nvidia.com>,
linux-kernel@vger.kernel.org,
Oleksij Rempel <linux@rempel-privat.de>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org, linux-kselftest@vger.kernel.org,
David Ahern <dsahern@gmail.com>, Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Shuah Khan <shuah@kernel.org>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [Bridge] [PATCH net-next v4 3/6] net: bridge: Track and limit dynamically learned FDB entries
Date: Tue, 26 Sep 2023 14:22:42 +0300 [thread overview]
Message-ID: <ZRK/ArWPNHgjVvWA@shredder> (raw)
In-Reply-To: <20230919-fdb_limit-v4-3-39f0293807b8@avm.de>
On Tue, Sep 19, 2023 at 10:12:50AM +0200, Johannes Nixdorf wrote:
> A malicious actor behind one bridge port may spam the kernel with packets
> with a random source MAC address, each of which will create an FDB entry,
> each of which is a dynamic allocation in the kernel.
>
> There are roughly 2^48 different MAC addresses, further limited by the
> rhashtable they are stored in to 2^31. Each entry is of the type struct
> net_bridge_fdb_entry, which is currently 128 bytes big. This means the
> maximum amount of memory allocated for FDB entries is 2^31 * 128B =
> 256GiB, which is too much for most computers.
>
> Mitigate this by maintaining a per bridge count of those automatically
> generated entries in fdb_n_learned, and a limit in fdb_max_learned. If
> the limit is hit new entries are not learned anymore.
>
> For backwards compatibility the default setting of 0 disables the limit.
>
> User-added entries by netlink or from bridge or bridge port addresses
> are never blocked and do not count towards that limit.
>
> Introduce a new fdb entry flag BR_FDB_DYNAMIC_LEARNED to keep track of
> whether an FDB entry is included in the count. The flag is enabled for
> dynamically learned entries, and disabled for all other entries. This
> should be equivalent to BR_FDB_ADDED_BY_USER and BR_FDB_LOCAL being unset,
> but contrary to the two flags it can be toggled atomically.
>
> Atomicity is required here, as there are multiple callers that modify the
> flags, but are not under a common lock (br_fdb_update is the exception
> for br->hash_lock, br_fdb_external_learn_add for RTNL).
>
> Signed-off-by: Johannes Nixdorf <jnixdorf-oss@avm.de>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
WARNING: multiple messages have this Message-ID (diff)
From: Ido Schimmel <idosch@idosch.org>
To: Johannes Nixdorf <jnixdorf-oss@avm.de>
Cc: "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>,
bridge@lists.linux-foundation.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net-next v4 3/6] net: bridge: Track and limit dynamically learned FDB entries
Date: Tue, 26 Sep 2023 14:22:42 +0300 [thread overview]
Message-ID: <ZRK/ArWPNHgjVvWA@shredder> (raw)
In-Reply-To: <20230919-fdb_limit-v4-3-39f0293807b8@avm.de>
On Tue, Sep 19, 2023 at 10:12:50AM +0200, Johannes Nixdorf wrote:
> A malicious actor behind one bridge port may spam the kernel with packets
> with a random source MAC address, each of which will create an FDB entry,
> each of which is a dynamic allocation in the kernel.
>
> There are roughly 2^48 different MAC addresses, further limited by the
> rhashtable they are stored in to 2^31. Each entry is of the type struct
> net_bridge_fdb_entry, which is currently 128 bytes big. This means the
> maximum amount of memory allocated for FDB entries is 2^31 * 128B =
> 256GiB, which is too much for most computers.
>
> Mitigate this by maintaining a per bridge count of those automatically
> generated entries in fdb_n_learned, and a limit in fdb_max_learned. If
> the limit is hit new entries are not learned anymore.
>
> For backwards compatibility the default setting of 0 disables the limit.
>
> User-added entries by netlink or from bridge or bridge port addresses
> are never blocked and do not count towards that limit.
>
> Introduce a new fdb entry flag BR_FDB_DYNAMIC_LEARNED to keep track of
> whether an FDB entry is included in the count. The flag is enabled for
> dynamically learned entries, and disabled for all other entries. This
> should be equivalent to BR_FDB_ADDED_BY_USER and BR_FDB_LOCAL being unset,
> but contrary to the two flags it can be toggled atomically.
>
> Atomicity is required here, as there are multiple callers that modify the
> flags, but are not under a common lock (br_fdb_update is the exception
> for br->hash_lock, br_fdb_external_learn_add for RTNL).
>
> Signed-off-by: Johannes Nixdorf <jnixdorf-oss@avm.de>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
next prev parent reply other threads:[~2023-09-26 11:22 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-19 8:12 [Bridge] [PATCH net-next v4 0/6] bridge: Add a limit on learned FDB entries Johannes Nixdorf
2023-09-19 8:12 ` Johannes Nixdorf
2023-09-19 8:12 ` [Bridge] [PATCH net-next v4 1/6] net: bridge: Set BR_FDB_ADDED_BY_USER early in fdb_add_entry Johannes Nixdorf
2023-09-19 8:12 ` Johannes Nixdorf
2023-09-20 10:44 ` [Bridge] " Nikolay Aleksandrov
2023-09-20 10:44 ` Nikolay Aleksandrov
2023-09-21 12:13 ` [Bridge] " Ido Schimmel
2023-09-21 12:13 ` Ido Schimmel
2023-09-19 8:12 ` [Bridge] [PATCH net-next v4 2/6] net: bridge: Set strict_start_type for br_policy Johannes Nixdorf
2023-09-19 8:12 ` Johannes Nixdorf
2023-09-20 10:46 ` [Bridge] " Nikolay Aleksandrov
2023-09-20 10:46 ` Nikolay Aleksandrov
2023-09-21 7:23 ` [Bridge] " Johannes Nixdorf
2023-09-21 7:23 ` Johannes Nixdorf
2023-09-21 10:14 ` [Bridge] " Nikolay Aleksandrov
2023-09-21 10:14 ` Nikolay Aleksandrov
2023-09-22 12:18 ` [Bridge] " Johannes Nixdorf
2023-09-22 12:18 ` Johannes Nixdorf
2023-09-19 8:12 ` [Bridge] [PATCH net-next v4 3/6] net: bridge: Track and limit dynamically learned FDB entries Johannes Nixdorf
2023-09-19 8:12 ` Johannes Nixdorf
2023-09-20 10:49 ` [Bridge] " Nikolay Aleksandrov
2023-09-20 10:49 ` Nikolay Aleksandrov
2023-09-26 11:22 ` Ido Schimmel [this message]
2023-09-26 11:22 ` Ido Schimmel
2023-09-19 8:12 ` [Bridge] [PATCH net-next v4 4/6] net: bridge: Add netlink knobs for number / max " Johannes Nixdorf
2023-09-19 8:12 ` Johannes Nixdorf
2023-09-20 10:50 ` [Bridge] " Nikolay Aleksandrov
2023-09-20 10:50 ` Nikolay Aleksandrov
2023-09-21 7:29 ` [Bridge] " Johannes Nixdorf
2023-09-21 7:29 ` Johannes Nixdorf
2023-09-21 12:41 ` [Bridge] " Nikolay Aleksandrov
2023-09-21 12:41 ` Nikolay Aleksandrov
2023-09-21 12:51 ` [Bridge] " Nikolay Aleksandrov
2023-09-21 12:51 ` Nikolay Aleksandrov
2023-09-19 8:12 ` [Bridge] [PATCH net-next v4 5/6] net: bridge: Add a configurable default FDB learning limit Johannes Nixdorf
2023-09-19 8:12 ` Johannes Nixdorf
2023-09-20 11:00 ` [Bridge] " Nikolay Aleksandrov
2023-09-20 11:00 ` Nikolay Aleksandrov
2023-09-21 8:06 ` [Bridge] " Johannes Nixdorf
2023-09-21 8:06 ` Johannes Nixdorf
2023-09-21 10:19 ` [Bridge] " Nikolay Aleksandrov
2023-09-21 10:19 ` Nikolay Aleksandrov
2023-09-26 11:42 ` [Bridge] " Ido Schimmel
2023-09-26 11:42 ` Ido Schimmel
2023-09-19 8:12 ` [Bridge] [PATCH net-next v4 6/6] selftests: forwarding: bridge_fdb_learning_limit: Add a new selftest Johannes Nixdorf
2023-09-19 8:12 ` Johannes Nixdorf
2023-09-20 11:01 ` [Bridge] " Nikolay Aleksandrov
2023-09-20 11:01 ` Nikolay Aleksandrov
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=ZRK/ArWPNHgjVvWA@shredder \
--to=idosch@idosch.org \
--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=jnixdorf-oss@avm.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.