From: Ido Schimmel <idosch@nvidia.com>
To: Jonas Gorski <jonas.gorski@bisdn.de>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>,
Roopa Prabhu <roopa@nvidia.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Hans Schultz <schultz.hans@gmail.com>,
"Hans J. Schultz" <netdev@kapio-technology.com>,
bridge@lists.linux.dev, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] net: bridge: handle ports in locked mode for ll learning
Date: Thu, 12 Dec 2024 14:25:42 +0200 [thread overview]
Message-ID: <Z1rWRorUo7ivWJdO@shredder> (raw)
In-Reply-To: <fb085904-e1c2-4bbf-b826-b6ba67d283b5@bisdn.de>
On Thu, Dec 12, 2024 at 10:50:10AM +0100, Jonas Gorski wrote:
> The original patch (just disabling LL learning if port is locked) has
> the same issue as mine, it will indirectly break switchdev offloading
> for case 2 when not using MAB (the kernel feature).
>
> Once we disable creating dynamic entries in the kernel, userspace needs
> to create them,
But the whole point of the "locked" feature is to defer the installation
of FDB entries to user space so that the control plane will be able to
decide which hosts can communicate through the bridge. Having the kernel
auto-populate the FDB based on incoming packets defeats this purpose,
which is why the man page mentions the "no_linklocal_learn" option and
why I think there is a very low risk of regressions from the original
patch.
> and userspace dynamic entries have the user bit set, which makes them
> get ignored by switchdev.
The second use case never worked correctly in the offload case. It is
not a regression.
>
> Ofc enabling MAB and then unlocking the locked entries hosts that
> successfully authenticated should still work for 2, as long as the host
> sent something other than link local traffic to create a (locked)
> dynamic entry AFAIU.
>
> FWIW, my proposed change/fix would be:
>
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index ceaa5a89b947..41b69ea300bf 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> @@ -238,7 +238,8 @@ static void __br_handle_local_finish(struct sk_buff *skb)
> nbp_state_should_learn(p) &&
> !br_opt_get(p->br, BROPT_NO_LL_LEARN) &&
> br_should_learn(p, skb, &vid))
> - br_fdb_update(p->br, p, eth_hdr(skb)->h_source, vid, 0);
> + br_fdb_update(p->br, p, eth_hdr(skb)->h_source, vid,
> + p->flags & BR_PORT_MAB ? BIT(BR_FDB_LOCKED) : 0);
IIUC, this will potentially roam FDB entries to unauthorized ports,
unlike the implementation in br_handle_frame_finish(). I documented it
in commit a35ec8e38cdd ("bridge: Add MAC Authentication Bypass (MAB)
support") in "1. Roaming".
> }
>
> /* note: already called with rcu_read_lock */
>
> which just makes sure that when MAB is enabled, link local learned
> entries are also locked. This relies on br_fdb_update() ignoring most
> flags for existing entries, not sure if this is a good idea though.
>
>
> Best Regards,
> Jonas
>
> --
> BISDN GmbH
> Körnerstraße 7-10
> 10785 Berlin
> Germany
>
>
> Phone:
> +49-30-6108-1-6100
>
>
> Managing Directors:
> Dr.-Ing. Hagen Woesner, Andreas
> Köpsel
>
>
> Commercial register:
> Amtsgericht Berlin-Charlottenburg HRB 141569
> B
> VAT ID No: DE283257294
>
next prev parent reply other threads:[~2024-12-12 12:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-10 14:06 [PATCH RFC] net: bridge: handle ports in locked mode for ll learning Jonas Gorski
2024-12-10 14:34 ` Vladimir Oltean
2024-12-10 14:47 ` Jonas Gorski
2024-12-10 14:55 ` Vladimir Oltean
2024-12-10 15:28 ` Jonas Gorski
2024-12-11 8:42 ` Ido Schimmel
2024-12-11 10:32 ` Jonas Gorski
2024-12-11 14:50 ` Ido Schimmel
2024-12-12 9:50 ` Jonas Gorski
2024-12-12 12:25 ` Ido Schimmel [this message]
2024-12-13 11:25 ` Jonas Gorski
2024-12-15 9:35 ` Ido Schimmel
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=Z1rWRorUo7ivWJdO@shredder \
--to=idosch@nvidia.com \
--cc=bridge@lists.linux.dev \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jonas.gorski@bisdn.de \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@kapio-technology.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.com \
--cc=schultz.hans@gmail.com \
--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;
as well as URLs for NNTP newsgroup(s).