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: <YFnf7arsXNbJpuBE@lunn.ch>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ