From: Ido Schimmel <idosch@nvidia.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: "Hans J. Schultz" <netdev@kapio-technology.com>,
davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
Florian Fainelli <f.fainelli@gmail.com>,
Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Kurt Kanzenbach <kurt@linutronix.de>,
Hauke Mehrtens <hauke@hauke-m.de>,
Woojung Huh <woojung.huh@microchip.com>,
UNGLinuxDriver@microchip.com, Sean Wang <sean.wang@mediatek.com>,
Landen Chao <Landen.Chao@mediatek.com>,
DENG Qingfang <dqfext@gmail.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Jiri Pirko <jiri@resnulli.us>, Ivan Vecera <ivecera@redhat.com>,
Roopa Prabhu <roopa@nvidia.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
Shuah Khan <shuah@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Christian Marangi <ansuelsmth@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Yuwei Wang <wangyuweihx@gmail.com>,
Petr Machata <petrm@nvidia.com>,
Florent Fourcot <florent.fourcot@wifirst.fr>,
Hans Schultz <schultz.hans@gmail.com>,
Joachim Wiberg <troglobit@gmail.com>,
Amit Cohen <amcohen@nvidia.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org,
bridge@lists.linux-foundation.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v8 net-next 05/12] net: dsa: propagate the locked flag down through the DSA layer
Date: Thu, 20 Oct 2022 18:23:37 +0300 [thread overview]
Message-ID: <Y1Fn+TnbI/uMH0VR@shredder> (raw)
In-Reply-To: <20221020141104.7h7kpau6cnpfqvh4@skbuf>
On Thu, Oct 20, 2022 at 05:11:04PM +0300, Vladimir Oltean wrote:
> On Thu, Oct 20, 2022 at 04:57:35PM +0300, Ido Schimmel wrote:
> > > Right now this packet isn't generated, right?
> >
> > Right. We don't support BR_PORT_LOCKED so these checks are not currently
> > enabled in hardware. To be clear, only packets received via locked ports
> > are able to trigger the check.
>
> You mean BR_PORT_MAB, not BR_PORT_LOCKED, right?
I actually meant BR_PORT_LOCKED... The hardware has a single bit per
port that can be used to enable security checks on the port. If security
checks are enabled, then before L2 forwarding the hardware will perform
an FDB lookup with the SMAC and FID (VID), which can have one of three
results:
1. Match. FDB entry found and it points to the ingress port. In this
case the packet continues to the regular L2 pipeline.
2. Mismatch. FDB entry found, but it points to a different port than
ingress port. In this case we want to drop the packet like the software
bridge.
3. Miss. FDB entry not found. Here I was thinking to always tell the
packet to go to the software data path so that it will trigger the
creation of the "locked" entry if MAB is enabled. If MAB is not enabled,
it will simply be dropped by the bridge. We can't control it per port in
hardware, which is why the BR_PORT_MAB flag is not consulted.
> AFAIU, "locked" means drop unknown MAC SA, "mab" means "install
> BR_FDB_LOCKED entry on port" (and also maybe still drop, if "locked"
> is also set on port).
Right, but you can't have "mab" without "locked" (from patch #1):
```
@@ -943,6 +946,13 @@ static int br_setport(struct net_bridge_port *p, struct nlattr *tb[],
br_set_port_flag(p, tb, IFLA_BRPORT_NEIGH_SUPPRESS, BR_NEIGH_SUPPRESS);
br_set_port_flag(p, tb, IFLA_BRPORT_ISOLATED, BR_ISOLATED);
br_set_port_flag(p, tb, IFLA_BRPORT_LOCKED, BR_PORT_LOCKED);
+ br_set_port_flag(p, tb, IFLA_BRPORT_MAB, BR_PORT_MAB);
+
+ if (!(p->flags & BR_PORT_LOCKED) && (p->flags & BR_PORT_MAB)) {
+ NL_SET_ERR_MSG(extack, "MAB cannot be enabled when port is unlocked");
+ p->flags = old_flags;
+ return -EINVAL;
+ }
changed_mask = old_flags ^ p->flags;
```
> Sad there isn't any good documentation about these flags in the patches
> that Hans is proposing.
Will try to comment with better commit messages for patches #1 and #2.
Not sure I will have time today.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-10-20 15:24 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-18 16:56 [PATCH v8 net-next 00/12] Extend locked port feature with FDB locked flag (MAC-Auth/MAB) Hans J. Schultz
2022-10-18 16:56 ` [PATCH v8 net-next 01/12] net: bridge: add locked entry fdb flag to extend locked port feature Hans J. Schultz
2022-10-20 12:54 ` Ido Schimmel
2022-10-20 19:37 ` netdev
2022-10-21 0:11 ` Jakub Kicinski
2022-10-18 16:56 ` [PATCH v8 net-next 02/12] net: bridge: add blackhole fdb entry flag Hans J. Schultz
2022-10-20 13:06 ` Ido Schimmel
2022-10-20 19:34 ` netdev
2022-10-23 5:32 ` netdev
2022-10-24 17:08 ` Jakub Kicinski
2022-10-18 16:56 ` [PATCH v8 net-next 03/12] net: bridge: enable bridge to install locked fdb entries from drivers Hans J. Schultz
2022-10-20 12:55 ` Vladimir Oltean
2022-10-20 19:29 ` netdev
2022-10-20 22:43 ` Vladimir Oltean
2022-10-18 16:56 ` [PATCH v8 net-next 04/12] net: bridge: add MAB flag to hardware offloadable flags Hans J. Schultz
2022-10-18 16:56 ` [PATCH v8 net-next 05/12] net: dsa: propagate the locked flag down through the DSA layer Hans J. Schultz
2022-10-20 13:02 ` Vladimir Oltean
2022-10-20 13:24 ` Ido Schimmel
2022-10-20 13:35 ` Vladimir Oltean
2022-10-20 13:57 ` Ido Schimmel
2022-10-20 14:04 ` Vladimir Oltean
2022-10-20 14:58 ` Ido Schimmel
2022-10-20 15:25 ` Vladimir Oltean
2022-10-20 14:11 ` Vladimir Oltean
2022-10-20 15:23 ` Ido Schimmel [this message]
2022-10-20 15:36 ` Vladimir Oltean
2022-10-20 18:47 ` netdev
2022-10-20 23:57 ` Vladimir Oltean
2022-10-20 19:43 ` netdev
2022-10-20 22:52 ` Vladimir Oltean
2022-10-18 16:56 ` [PATCH v8 net-next 06/12] net: bridge: enable bridge to send and receive blackhole FDB entries Hans J. Schultz
2022-10-18 16:56 ` [PATCH v8 net-next 07/12] net: dsa: send the blackhole flag down through the DSA layer Hans J. Schultz
2022-10-18 16:56 ` [PATCH v8 net-next 08/12] drivers: net: dsa: add fdb entry flags incoming to switchcore drivers Hans J. Schultz
2022-10-20 13:12 ` Vladimir Oltean
2022-10-18 16:56 ` [PATCH v8 net-next 09/12] net: dsa: mv88e6xxx: allow reading FID when handling ATU violations Hans J. Schultz
2022-10-18 16:56 ` [PATCH v8 net-next 10/12] net: dsa: mv88e6xxx: mac-auth/MAB implementation Hans J. Schultz
2022-10-20 13:25 ` Vladimir Oltean
2022-10-20 19:59 ` netdev
2022-10-20 20:20 ` netdev
2022-10-20 22:57 ` Vladimir Oltean
2022-10-21 6:47 ` netdev
2022-10-21 11:22 ` Vladimir Oltean
2022-10-21 13:16 ` netdev
2022-10-21 16:30 ` Vladimir Oltean
2022-10-21 17:18 ` netdev
2022-10-21 17:30 ` Vladimir Oltean
2022-10-21 17:39 ` netdev
2022-10-21 18:14 ` Vladimir Oltean
2022-10-22 7:24 ` netdev
2022-10-22 12:02 ` Vladimir Oltean
2022-10-22 13:15 ` netdev
2022-10-22 8:50 ` Oleksandr Mazur
2022-10-22 11:32 ` Vladimir Oltean
2022-10-22 12:55 ` Oleksandr Mazur
2022-10-22 13:39 ` Vladimir Oltean
2022-10-22 13:49 ` Ido Schimmel
2022-10-22 14:11 ` netdev
2022-10-22 14:49 ` Vladimir Oltean
2022-10-23 6:53 ` Ido Schimmel
2022-10-20 21:09 ` netdev
2022-10-20 23:00 ` Vladimir Oltean
2022-10-22 7:31 ` netdev
2022-10-22 11:55 ` Vladimir Oltean
2022-10-18 16:56 ` [PATCH v8 net-next 11/12] net: dsa: mv88e6xxx: add blackhole ATU entries Hans J. Schultz
2022-10-20 13:11 ` Vladimir Oltean
2022-10-18 16:56 ` [PATCH v8 net-next 12/12] selftests: forwarding: add MAB tests to locked port tests Hans J. Schultz
2022-10-20 12:35 ` Ido Schimmel
2022-10-19 18:58 ` [PATCH v8 net-next 00/12] Extend locked port feature with FDB locked flag (MAC-Auth/MAB) Jakub Kicinski
2022-10-20 9:55 ` 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=Y1Fn+TnbI/uMH0VR@shredder \
--to=idosch@nvidia.com \
--cc=Landen.Chao@mediatek.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=amcohen@nvidia.com \
--cc=andrew@lunn.ch \
--cc=ansuelsmth@gmail.com \
--cc=bridge@lists.linux-foundation.org \
--cc=claudiu.manoil@nxp.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dqfext@gmail.com \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=florent.fourcot@wifirst.fr \
--cc=hauke@hauke-m.de \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=kurt@linutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=matthias.bgg@gmail.com \
--cc=netdev@kapio-technology.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.com \
--cc=schultz.hans@gmail.com \
--cc=sean.wang@mediatek.com \
--cc=shuah@kernel.org \
--cc=troglobit@gmail.com \
--cc=vivien.didelot@gmail.com \
--cc=wangyuweihx@gmail.com \
--cc=woojung.huh@microchip.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).