netdev - Re: commit 4c7ea3c0791e (net: dsa: mv88e6xxx: disable SA learning for DSA and CPU ports)

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]

Message-ID: <20210118211924.u2bl6ynmo5kdyyff@skbuf>
Date:   Mon, 18 Jan 2021 23:19:24 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Tobias Waldekranz <tobias@...dekranz.com>
Cc:     Rasmus Villemoes <rasmus.villemoes@...vas.dk>,
        Andrew Lunn <andrew@...n.ch>,
        Network Development <netdev@...r.kernel.org>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>
Subject: Re: commit 4c7ea3c0791e (net: dsa: mv88e6xxx: disable SA learning
 for DSA and CPU ports)

On Sat, Jan 16, 2021 at 02:42:12AM +0100, Tobias Waldekranz wrote:
> > What I'm _really_ trying to do is to get my mv88e6250 to participate in
> > an MRP ring, which AFAICT will require that the master device's MAC gets
> > added as a static entry in the ATU: Otherwise, when the ring goes from
> > open to closed, I've seen the switch wrongly learn the node's own mac
> > address as being in the direction of one of the normal ports, which
> > obviously breaks all traffic. So if the topology is
> >
> >    M
> >  /   \
> > C1 *** C2
> >
> > with the link between C1 and C2 being broken, both M-C1 and M-C2 links
> > are in forwarding (hence learning) state, so when the C1-C2 link gets
> > reestablished, it will take at least one received test packet for M to
> > decide to put one of the ports in blocking state - by which time the
> > damage is done, and the ATU now has a broken entry for M's own mac address.

What hardware offload features do you need to use for MRP on mv88e6xxx?
If none, then considering that Tobias's bridge series may stall, I think
by far the easiest approach would be for DSA to detect that it can't
offload the bridge+MRP configuration, and keep all ports as standalone.
When in standalone mode, the ports don't offload any bridge flags, i.e.
they don't do address learning, and the only forwarding destination
allowed is the CPU. The only disadvantage is that this is software-based
forwarding.