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]

Message-ID: <CA+h21hpFwQyW0HwYpMRgBHBn51ySR_SxS5eDQ2ixwqiEbLj2mA@mail.gmail.com>
Date:   Tue, 18 Feb 2020 16:05:08 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
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

Hi Andrew,

On Tue, 18 Feb 2020 at 16:01, Andrew Lunn <andrew@...n.ch> wrote:
>
> 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.

Promisc on the DSA master is not why this works. The switch drops the
packets instead of forwarding them to the CPU, because the CPU is not
in the list of valid destination for unknown unicast traffic received
on the front panel ports.
Promiscuous mode on the DSA master is also disabled when the switch
ports exit the bridge, by the way.

>
>        Andrew

Regards,
-Vladimir