netdev - Re: [PATCH v3 net-next 5/8] net: dsa: felix: support psfp filter on vsc9959

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] [day] [month] [year] [list]

Date:   Thu, 9 Sep 2021 12:01:21 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Joergen Andreasen <joergen.andreasen@...rochip.com>
CC:     Xiaoliang Yang <xiaoliang.yang_1@....com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "allan.nielsen@...rochip.com" <allan.nielsen@...rochip.com>,
        "UNGLinuxDriver@...rochip.com" <UNGLinuxDriver@...rochip.com>,
        "vinicius.gomes@...el.com" <vinicius.gomes@...el.com>,
        "michael.chan@...adcom.com" <michael.chan@...adcom.com>,
        "saeedm@...lanox.com" <saeedm@...lanox.com>,
        "jiri@...lanox.com" <jiri@...lanox.com>,
        "idosch@...lanox.com" <idosch@...lanox.com>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "kuba@...nel.org" <kuba@...nel.org>, Po Liu <po.liu@....com>,
        Leo Li <leoyang.li@....com>
Subject: Re: [PATCH v3 net-next 5/8] net: dsa: felix: support psfp filter on
 vsc9959

On Thu, Sep 09, 2021 at 01:33:57PM +0200, Joergen Andreasen wrote:
> > > Yes, Using redirect action can give PSFP filter a forward port to
> > > add
> > > MAC table entry. But it also has the issue that when using "bridge
> > > fdb
> > > del" to delete the MAC entry will cause the tc-filter rule not
> > > working.
> >
> > We need to define the expected behavior.
> >
> > As far as the 802.1Q-2018 spec is concerned, there is no logical
> > dependency between the FDB lookup and the PSFP streams. But there
> > seems
> > to be no explicit text that forbids it either, though.
> >
> > If you install a tc-redirect rule and offload it as a bridge FDB
> > entry,
> > it needs to behave like a tc-redirect rule and not a bridge FDB
> > entry.
> > So it only needs to match on the intended source port. I don't
> > believe
> > that is possible. If it is, let's do that.
> >
> > To me, putting PSFP inside the bridge driver is completely outside of
> > the question. There is no evidence that it belongs there, and there
> > are
> > switch implementations from other vendors where the FDB lookup
> > process
> > is completely independent from the Qci stream identification process.
> > Anyway, this strategy of combining the two could only work for the
> > NULL
> > stream identifiers in the first place (MAC DA + VLAN ID), not for the
> > others (IP Stream identification etc etc).
> >
> > So what remains, if nothing else is possible, is to require the user
> > to
> > manage the bridge FDB entries, and make sure that the kernel side is
> > sane, and does not remain with broken data structures. That is going
> > to
> > be a PITA both for the user and for the kernel side, because we are
> > going to make the tc-flower filters effectively depend upon the
> > bridge
> > state.
> >
> > Let's wait for some feedback from Microchip engineers, how they
> > envisioned this to be integrated with operating systems.
>
> We at Microchip agrees that it is a difficult task to map the PSFP
> implementation in Felix to the “tc flower” filter command, but please
> remember that Ocelot and its derivatives were designed long before
> the 802.1Qci standard was ratified and also before anyone has
> considered how to control it in Linux.
>
> We think that the best approach is to require the user to manage
> bridge FDB entries manually as suggested by Xiaoliang.
>
> Our newer PSFP designs uses the TCAM instead of the MAC table
> which maps a lot better to the “tc flower” filter command.

Well, that's even more unfortunate, because as explained by Ido here:
https://lore.kernel.org/netdev/YSHzLKpixhCrrgJ0@shredder/

the return code from SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE event handlers is
not propagated to br_switchdev_fdb_notify. So in effect, the device driver
cannot stop the bridge from removing an FDB entry which would lead it to
having a broken tc filter.

Now, the ocelot switchdev driver uses the bridge bypass .ndo_fdb_add and
.ndo_fdb_del, while DSA actually listens for switchdev events on the
atomic call chain. So any solution needs to work with switchdev, not
just with the bridge bypass ops.