| 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
| ||
|
Date: Wed, 6 Jan 2021 09:43:25 -0800
From: Florian Fainelli <f.fainelli@...il.com>
To: Vladimir Oltean <olteanv@...il.com>, Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, bridge@...ts.linux-foundation.org,
Roopa Prabhu <roopa@...dia.com>,
Nikolay Aleksandrov <nikolay@...dia.com>,
"David S. Miller" <davem@...emloft.net>
Cc: DENG Qingfang <dqfext@...il.com>,
Tobias Waldekranz <tobias@...dekranz.com>,
Marek Behun <marek.behun@....cz>,
Russell King - ARM Linux admin <linux@...linux.org.uk>,
Alexandra Winter <wintera@...ux.ibm.com>,
Jiri Pirko <jiri@...nulli.us>,
Ido Schimmel <idosch@...sch.org>,
Claudiu Manoil <claudiu.manoil@....com>,
UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH v4 net-next 1/7] net: bridge: notify switchdev of
disappearance of old FDB entry upon migration
On 1/6/21 1:51 AM, Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@....com>
>
> Currently the bridge emits atomic switchdev notifications for
> dynamically learnt FDB entries. Monitoring these notifications works
> wonders for switchdev drivers that want to keep their hardware FDB in
> sync with the bridge's FDB.
>
> For example station A wants to talk to station B in the diagram below,
> and we are concerned with the behavior of the bridge on the DUT device:
>
> DUT
> +-------------------------------------+
> | br0 |
> | +------+ +------+ +------+ +------+ |
> | | | | | | | | | |
> | | swp0 | | swp1 | | swp2 | | eth0 | |
> +-------------------------------------+
> | | |
> Station A | |
> | |
> +--+------+--+ +--+------+--+
> | | | | | | | |
> | | swp0 | | | | swp0 | |
> Another | +------+ | | +------+ | Another
> switch | br0 | | br0 | switch
> | +------+ | | +------+ |
> | | | | | | | |
> | | swp1 | | | | swp1 | |
> +--+------+--+ +--+------+--+
> |
> Station B
>
> Interfaces swp0, swp1, swp2 are handled by a switchdev driver that has
> the following property: frames injected from its control interface bypass
> the internal address analyzer logic, and therefore, this hardware does
> not learn from the source address of packets transmitted by the network
> stack through it. So, since bridging between eth0 (where Station B is
> attached) and swp0 (where Station A is attached) is done in software,
> the switchdev hardware will never learn the source address of Station B.
> So the traffic towards that destination will be treated as unknown, i.e.
> flooded.
>
> This is where the bridge notifications come in handy. When br0 on the
> DUT sees frames with Station B's MAC address on eth0, the switchdev
> driver gets these notifications and can install a rule to send frames
> towards Station B's address that are incoming from swp0, swp1, swp2,
> only towards the control interface. This is all switchdev driver private
> business, which the notification makes possible.
>
> All is fine until someone unplugs Station B's cable and moves it to the
> other switch:
>
> DUT
> +-------------------------------------+
> | br0 |
> | +------+ +------+ +------+ +------+ |
> | | | | | | | | | |
> | | swp0 | | swp1 | | swp2 | | eth0 | |
> +-------------------------------------+
> | | |
> Station A | |
> | |
> +--+------+--+ +--+------+--+
> | | | | | | | |
> | | swp0 | | | | swp0 | |
> Another | +------+ | | +------+ | Another
> switch | br0 | | br0 | switch
> | +------+ | | +------+ |
> | | | | | | | |
> | | swp1 | | | | swp1 | |
> +--+------+--+ +--+------+--+
> |
> Station B
>
> Luckily for the use cases we care about, Station B is noisy enough that
> the DUT hears it (on swp1 this time). swp1 receives the frames and
> delivers them to the bridge, who enters the unlikely path in br_fdb_update
> of updating an existing entry. It moves the entry in the software bridge
> to swp1 and emits an addition notification towards that.
>
> As far as the switchdev driver is concerned, all that it needs to ensure
> is that traffic between Station A and Station B is not forever broken.
> If it does nothing, then the stale rule to send frames for Station B
> towards the control interface remains in place. But Station B is no
> longer reachable via the control interface, but via a port that can
> offload the bridge port learning attribute. It's just that the port is
> prevented from learning this address, since the rule overrides FDB
> updates. So the rule needs to go. The question is via what mechanism.
>
> It sure would be possible for this switchdev driver to keep track of all
> addresses which are sent to the control interface, and then also listen
> for bridge notifier events on its own ports, searching for the ones that
> have a MAC address which was previously sent to the control interface.
> But this is cumbersome and inefficient. Instead, with one small change,
> the bridge could notify of the address deletion from the old port, in a
> symmetrical manner with how it did for the insertion. Then the switchdev
> driver would not be required to monitor learn/forget events for its own
> ports. It could just delete the rule towards the control interface upon
> bridge entry migration. This would make hardware address learning be
> possible again. Then it would take a few more packets until the hardware
> and software FDB would be in sync again.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
> Acked-by: Nikolay Aleksandrov <nikolay@...dia.com>
> Reviewed-by: Ido Schimmel <idosch@...dia.com>
> Reviewed-by: Andrew Lunn <andrew@...n.ch>
Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
--
Florian
Powered by blists - more mailing lists