netdev - Re: [PATCH net-next] net: dsa: tag_rtl4_a: Drop bit 9 from egress frames

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]

Message-ID: <20210923231145.pmbr6py32owurmic@skbuf>
Date:   Fri, 24 Sep 2021 02:11:45 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     DENG Qingfang <dqfext@...il.com>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] net: dsa: tag_rtl4_a: Drop bit 9 from egress
 frames

On Fri, Sep 24, 2021 at 12:58:00AM +0200, Linus Walleij wrote:
> On Fri, Sep 24, 2021 at 12:25 AM Vladimir Oltean <olteanv@...il.com> wrote:
> > On Fri, Sep 24, 2021 at 12:21:39AM +0200, Linus Walleij wrote:
> > > > > Do we have some use for that feature in DSA taggers?
> > > >
> > > > Yes.
> > >
> > > OK I'll add it to my TODO, right now trying to fix up the base
> > > of the RTL8366RB patch set to handle VLANs the right way.
> >
> > But you didn't ask what that use is...
> 
> Allright spill the beans :D I might not be the most clever at times...

So the essence of the answer is in the discussion we've already had on
your v1 attempt to disable this "unknown" bit:
https://patchwork.kernel.org/project/netdevbpf/patch/20210828235619.249757-1-linus.walleij@linaro.org/

The idea is that bridges should learn only from data plane packets, and
the only chance a DSA tagger has to distinguish between a data and a
control packet sent by the network stack is to look at
skb->offload_fwd_mark, which will be set on xmit by the bridge driver,
if you implement the .port_bridge_tx_fwd_offload and .port_bridge_tx_fwd_unoffload
methods, and declare a non-zero ds->max_num_bridges value (note: the API
for bridge TX forwarding offload in DSA is subject to change/get
simplified during this development cycle). And to offload the replication
for data packets correctly, you should really re-read the discussion we
had about what happens when the egress port mask set by the tagger is all-zeroes.

Not to blow my own horn or anything, but I've repeated this stuff for so many
times now that I wrote it down for future reference, you can find the basic
concepts detailed in chapter "The data plane and the control plane" from the
paper attached here (there are also pictures, not sure how much they help):
https://linuxplumbersconf.org/event/11/contributions/949/