netdev - Re: [PATCH net-next] net: mscc: ocelot: Workaround to allow traffic to CPU in standalone mode

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:   Tue, 18 Feb 2020 15:01:11 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     "Allan W. Nielsen" <allan.nielsen@...rochip.com>,
        "David S. Miller" <davem@...emloft.net>,
        Horatiu Vultur <horatiu.vultur@...rochip.com>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Joergen Andreasen <joergen.andreasen@...rochip.com>,
        Claudiu Manoil <claudiu.manoil@....com>,
        netdev <netdev@...r.kernel.org>,
        Microchip Linux Driver Support <UNGLinuxDriver@...rochip.com>
Subject: Re: [PATCH net-next] net: mscc: ocelot: Workaround to allow traffic
 to CPU in standalone mode

On Tue, Feb 18, 2020 at 02:29:15PM +0200, Vladimir Oltean wrote:
> Hi Allan,
> 
> On Tue, 18 Feb 2020 at 13:32, Allan W. Nielsen
> <allan.nielsen@...rochip.com> wrote:
> >
> > On 17.02.2020 17:00, Vladimir Oltean wrote:
> > >EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> > >
> > >From: Vladimir Oltean <vladimir.oltean@....com>
> > >
> > >The Ocelot switches have what is, in my opinion, a design flaw: their
> > >DSA header is in front of the Ethernet header, which means that they
> > >subvert the DSA master's RX filter, which for all practical purposes,
> > >either needs to be in promiscuous mode, or the OCELOT_TAG_PREFIX_LONG
> > >needs to be used for extraction, which makes the switch add a fake DMAC
> > >of ff:ff:ff:ff:ff:ff so that the DSA master accepts the frame.
> > >
> > >The issue with this design, of course, is that the CPU will be spammed
> > >with frames that it doesn't want to respond to, and there isn't any
> > >hardware offload in place by default to drop them.
> > In the case of Ocelot, the NPI port is expected to be connected back to
> > back to the CPU, meaning that it should not matter what DMAC is set.
> >
> 
> You are omitting the fact that the host Ethernet port has an RX filter
> as well. By default it should drop frames that aren't broadcast or
> aren't sent to a destination MAC equal to its configured MAC address.
> Most DSA switches add their tag _after_ the Ethernet header. This
> makes the DMAC and SMAC seen by the front-panel port of the switch be
> the same as the DMAC and SMAC seen by the host port. Combined with the
> fact that DSA sets up switch port MAC addresses to be inherited from
> the host port, RX filtering 'just works'.

It is a little bit more complex than that, but basically yes. If the
slave interface is in promisc mode, the master interface is also made
promisc. So as soon as you add a slave to a bridge, the master it set
promisc. Also, if the slave has a different MAC address to the master,
the MAC address is added to the masters RX filter.

If the DSA header is before the DMAC, you need promisc mode all the
time. But i don't expect the CPU port to be spammed. The switch should
only be forwarding frames to the CPU which the CPU is actually
interested in.

> Be there 4 net devices: swp0, swp1, swp2, swp3.
> At probe time, the following doesn't work on the Felix DSA driver:
> ip addr add 192.168.1.1/24 dev swp0
> ping 192.168.1.2

That is expected to work.

> But if I do this:
> ip link add dev br0 type bridge
> ip link set dev swp0 master br0
> ip link set dev swp0 nomaster
> ping 192.168.1.2
> Then it works, because the code path from ocelot_bridge_stp_state_set
> that puts the CPU port in the forwarding mask of the other ports gets
> executed on the "bridge leave" action.

It probably also works because when the port is added to the bridge,
the bridge puts the port into promisc mode. That in term causes the
master to be put into promisc mode.

       Andrew