netdev - Re: [PATCH net-next 00/10] DSA unicast filtering

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:   Thu, 3 Mar 2022 12:16:26 +0000
From:   Alvin Šipraga <ALSI@...g-olufsen.dk>
To:     Vladimir Oltean <vladimir.oltean@....com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        Ido Schimmel <idosch@...dia.com>,
        Tobias Waldekranz <tobias@...dekranz.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>
Subject: Re: [PATCH net-next 00/10] DSA unicast filtering

Hi Vladimir,

Vladimir Oltean <vladimir.oltean@....com> writes:

> This series doesn't attempt anything extremely brave, it just changes
> the way in which standalone ports which support FDB isolation work.
>
> Up until now, DSA has recommended that switch drivers configure
> standalone ports in a separate VID/FID with learning disabled, and with
> the CPU port as the only destination, reached trivially via flooding.
> That works, except that standalone ports will deliver all packets to the
> CPU. We can leverage the hardware FDB as a MAC DA filter, and disable
> flooding towards the CPU port, to force the dropping of packets with
> unknown MAC DA.
>
> We handle port promiscuity by re-enabling flooding towards the CPU port.
> This is relevant because the bridge puts its automatic (learning +
> flooding) ports in promiscuous mode, and this makes some things work
> automagically, like for example bridging with a foreign interface.
> We don't delve yet into the territory of managing CPU flooding more
> aggressively while under a bridge.
>
> The only switch driver that benefits from this work right now is the
> NXP LS1028A switch (felix). The others need to implement FDB isolation
> first, before DSA is going to install entries to the port's standalone
> database. Otherwise, these entries might collide with bridge FDB/MDB
> entries.
>
> This work was done mainly to have all the required features in place
> before somebody starts seriously architecting DSA support for multiple
> CPU ports. Otherwise it is much more difficult to bolt these features on
> top of multiple CPU ports.

So, previously FDB entries were only installed on bridged ports. Now you
also want to install FDB entries on standalone ports so that flooding
can be disabled on standalone ports for the reasons stated in your cover
letter.

To implement FDB isolation in a DSA driver, a typical approach might be
to use a filter ID (FID) for the FDB entries that is unique per
bridge. That is, since FDB entries were only added on bridged ports
(through learning or static entries added by software), the DSA driver
could readily use the bridge_num of the bridge that is being offloaded
to select the FID. The same bridge_num/FID would be used by the hardware
for lookup/learning on the given port.

If the above general statements are correct-ish, then my question here
is: what should be the FID - or other equivalent unique identifier used
by the hardware for FDB isolation - when the port is not offloading a
bridge, but is standalone? If FDB isolation is implemented in hardware
with something like FIDs, then do all standalone ports need to have a
unique FID?

For some context: I have been working on implementing offload features
for the rtl8365mb driver and I can also support FDB isolation between
bridged ports. The number of offloaded bridges is bounded by the number
of FIDs available, which is 8. For standalone ports I use a reserved
FID=0 which currently would never match any entries in the FDB, because
learning is disabled on standalone ports and Linux does not install any
FDB entries. When placed in a bridge, the FID of that port is then set
to bridge_num, which - rather conveniently - is indexed by 1.

Your change seems to introduce a more generic concept of per-port
FDB. How should one model the per-port FDB in hardware which uses FIDs?
Should I ensure that all ports - standalone by default - start with a
unique FID? That will be OK for switches with up to 8 ports, but for
switches with more ports, I'm a but puzzled as to what I can do. Do I
then have to declare that FDB isolation is unsupported
(fdb_isolation=0)?

Hope the question makes sense.

Kind regards,
Alvin