netdev - Re: [PATCH net-next] net: dsa: mv88e6xxx: Allow dynamic reconfiguration of tag protocol

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, 23 Mar 2021 13:32:45 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Tobias Waldekranz <tobias@...dekranz.com>, davem@...emloft.net,
        kuba@...nel.org, vivien.didelot@...il.com, f.fainelli@...il.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: dsa: mv88e6xxx: Allow dynamic
 reconfiguration of tag protocol

On Tue, Mar 23, 2021 at 01:35:22PM +0200, Vladimir Oltean wrote:
> On Tue, Mar 23, 2021 at 11:23:26AM +0100, Tobias Waldekranz wrote:
> > All devices are capable of using regular DSA tags. Support for
> > Ethertyped DSA tags sort into three categories:
> > 
> > 1. No support. Older chips fall into this category.
> > 
> > 2. Full support. Datasheet explicitly supports configuring the CPU
> >    port to receive FORWARDs with a DSA tag.
> > 
> > 3. Undocumented support. Datasheet lists the configuration from
> >    category 2 as "reserved for future use", but does empirically
> >    behave like a category 2 device.
> > 
> > Because there are ethernet controllers that do not handle regular DSA
> > tags in all cases, it is sometimes preferable to rely on the
> > undocumented behavior, as the alternative is a very crippled
> > system. But, in those cases, make sure to log the fact that an
> > undocumented feature has been enabled.
> > 
> > Signed-off-by: Tobias Waldekranz <tobias@...dekranz.com>
> > ---
> > 
> > In a system using an NXP T1023 SoC connected to a 6390X switch, we
> > noticed that TO_CPU frames where not reaching the CPU. This only
> > happened on hardware port 8. Looking at the DSA master interface
> > (dpaa-ethernet) we could see that an Rx error counter was bumped at
> > the same rate. The logs indicated a parser error.
> > 
> > It just so happens that a TO_CPU coming in on device 0, port 8, will
> > result in the first two bytes of the DSA tag being one of:
> > 
> > 00 40
> > 00 44
> > 00 46
> > 
> > My guess is that since these values look like 802.3 length fields, the
> > controller's parser will signal an error if the frame length does not
> > match what is in the header.
> 
> Interesting assumption.
> Could you please try this patch out, just for my amusement? It is only
> compile-tested.

Another thing you could try, just for amusement, is change the
Ethertype in EDSA to 00400044 and see if it also causes problems. It
might not, since the last two bytes are not set as required.

      Andrew