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:   Wed, 24 Mar 2021 15:24:01 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Tobias Waldekranz <tobias@...dekranz.com>
Cc:     davem@...emloft.net, kuba@...nel.org, andrew@...n.ch,
        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 Wed, Mar 24, 2021 at 02:01:14PM +0100, Tobias Waldekranz wrote:
> On Wed, Mar 24, 2021 at 13:34, Vladimir Oltean <olteanv@...il.com> wrote:
> > On Wed, Mar 24, 2021 at 11:52:49AM +0100, Tobias Waldekranz wrote:
> >> >> This is the tragedy: I know for a fact that a DSA soft parser exists,
> >> >> but because of the aforementioned maze of NDAs and license agreements
> >> >> we, the community, cannot have nice things.
> >> >
> >> > Oh yeah? You can even create your own, if you have nerves of steel and a
> >> > thick enough skin to learn to use the "fmc" (Frame Manager Configuration
> >> > Tool) program, which is fully open source if you search for it on CAF
> >> > (and if you can actually make something out of the source code).
> >> 
> >> Yes, this is what a colleague of mine has done. Which is how I know that
> >> one exists :)
> >> 
> >> > And this PDF (hidden so well behind the maze of NDAs, that I just had to
> >> > google for it, and you don't even need to register to read it):
> >> > https://www.nxp.com/docs/en/user-guide/LSDKUG_Rev20.12.pdf
> >> > is chock full of information on what you can do with it, see chapters 8.2.5 and 8.2.6.
> >> 
> >> Right, but this is where it ends. Using the wealth of information you
> >> have laid out so far you can use DPAA to do amazing things using open
> >> components.
> >> 
> >> ...unless you have to do something so incredibly advanced and exotic as
> >> a masked update of a field. At this point you have two options:
> >> 
> >> 1. Buy the firmware toolchain, which requires signing an NDA.
> >> 2. Buy a single-drop firmware binary for lots of $$$ without any
> >>    possibility of getting further updates because "you should really be
> >>    using DPAA2".
> >
> > Uhm, what?
> > By "firmware" I assume you mean "FMan microcode"?
> >
> > To my knowledge, the standard FMan microcode distributed _freely_ with
> > the LSDK has support for Header Manipulation, you just need to create a
> > Header Manipulation Command Descriptor (HMCD) and pass it to the
> > microcode through an O/H port. I believe that:
> > (a) the Header Manipulation descriptors allow you to perform raw mask
> >     based field updates too, not just for standard protocols
> 
> This is not the story we were told.

Wait, aren't we talking about HdrMan OPCODE 0x19 ("Replace Field in Header")?

> > (b) fmc already has some support for sending Header Manipulation
> >     descriptors to the microcode
> >
> > And by "firmware toolchain" you mean the FMan microcode SDK?
> > https://www.nxp.com/design/software/embedded-software/linux-software-and-development-tools/dpaa-fman-microcode-sdk-source-code-software-kit:DPAA-FMAN-SDK
> >
> > In the description for that product it says:
> >
> >   For MOST of NXP communications customers, the microcode that is freely
> >   accessible via the NXP LSDK or SDK for QorIQ or Layerscape processors
> >   will handle any communications offload task you could throw at the DPAA.
> >
> > So why on earth would you need that? And does it really surprise you
> 
> Because NXP said we needed it.
> 
> > that it costs money, especially considering the fact that you're going
> > to need heaps of support for it anyway?
> 
> No, it surprised me that we had to pay for a solution to a problem that
> we were promised would be solvable using the stock firmware.

Maybe the FMan version of your particular device does not support that
HM command, or maybe you needed a slightly different behavior compared
to what HM opcode 0x19 does, and there was a misunderstanding on either
ends resulting in the impression that what you need could be achievable
through that type of descriptor? Either way, the way you phrased things:
| unless you have to do something so incredibly advanced and exotic as
| a masked update of a field
is very unfair, oversimplifying and misleading.

> > Seriously, what is your point? You're complaining about having the
> > option to write your own microcode for the RISC cores inside the network
> > controller, when the standard one already comes with a lot of features?
> > What would you prefer, not having that option?
> >
> > This is a strawman. None of the features we talked about in this thread,
> > soft parser for DSA tags or masked header manipulation, should require
> > custom microcode.
> 
> I never made that claim. I was describing our experience with DPAA on
> the whole.

I fail to see how we ended up talking about custom FMan microcode then.
I did not bring it up, and it is completely irrelevant to the discussion
about soft parser for DSA.