netdev - Re: [PATCH net-next 0/2] bridge: FDB: Notify about removal of non-user-added entries

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 02 May 2018 01:27:20 +0300
From:   Petr Machata <petrm@...lanox.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, ivecera@...hat.com, davem@...emloft.net,
        stephen@...workplumber.org, vivien.didelot@...oirfairelinux.com,
        f.fainelli@...il.com, jiri@...nulli.us
Subject: Re: [PATCH net-next 0/2] bridge: FDB: Notify about removal of non-user-added entries

Andrew Lunn <andrew@...n.ch> writes:

> On Tue, May 01, 2018 at 07:04:19PM +0200, Petr Machata wrote:
>> Device drivers may generally need to keep in sync with bridge's FDB. In
>> particular, for its offload of tc mirror action where the mirrored-to
>> device is a gretap device, mlxsw needs to listen to a number of events.
>> SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE would be a natural notification to
>> listen to in order to keep up with FDB updates.
>> 
>> However, for removal of FDB entries added due to device activity (as
>> opposed to explicit addition through "bridge fdb add" or similar), there
>> are no notifications.
>
> Could you explain this some more. Why is mlxsw special in that it
> needs this, but other drivers don't. The b53 driver supports tc
> mirror, for example.

mlxsw supports offload of tc mirror to a gretap netdevice to achieve
mirroring of traffic encapsulated in GRE. However, the device doesn't do
routing and switching on the encapsulated mirrored packets. You need to
configure exact parameters--L2 and L3 addresses, VLAN tagging if any,
etc., and a single front panel port to forward to.

To offload this, the driver sort of plays the game of networking stack.
Finds the underlay route, finds the neighbor to get the Ethernet address
(and possibly kick starts ARP resolution), and if the target netdevice
is a bridge, queries the FDB to find the one port to forward to (and
bails out if it needs to flood, we can't really offload that).

Now any time anything in that pipeline changes, the stuff after that
point needs to be redone, and the offloading decision (if and how) may
change.

So if an administrator decides to remove an FDB entry by hand, the
driver should notice this and reflect the intent by removing offloads
that depend on existence of that FDB entry. But since there's no event,
mlxsw doesn't notice this outright. It does notice later, because of an
unrelated event--e.g. from a neighbor, a FIB notification, whatever it
happens to be. That discrepancy is what I'm trying to fix.

Thanks,
Petr