linux-kernel - Re: [PATCH v3 net-next 18/24] net: dsa: sja1105: Add support for traffic through standalone ports

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:   Mon, 15 Apr 2019 01:30:46 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>, vivien.didelot@...il.com,
        davem@...emloft.net, netdev <netdev@...r.kernel.org>,
        linux-kernel@...r.kernel.org,
        Georg Waibel <georg.waibel@...sor-technik.de>
Subject: Re: [PATCH v3 net-next 18/24] net: dsa: sja1105: Add support for
 traffic through standalone ports

On Sun, 14 Apr 2019 at 22:13, Andrew Lunn <andrew@...n.ch> wrote:
>
> On Sun, Apr 14, 2019 at 09:53:42PM +0300, Vladimir Oltean wrote:
> > On Sun, 14 Apr 2019 at 19:18, Andrew Lunn <andrew@...n.ch> wrote:
> > >
> > > > > > > > +             return dsa_8021q_xmit(skb, netdev, ETH_P_EDSA,
> > > > > > > > +                                  ((pcp << VLAN_PRIO_SHIFT) | tx_vid));
> > > > > > >
> > > > > > > Please don't reuse ETH_P_EDSA. Define an ETH_P_SJA1105.
> > > > > > >
> > > >
> > > > I'm receiving contradictory advice on this. Why should I define a new
> > > > ethertype, and if I do, what scope should the definition have (local
> > > > to the driver and the tagger, local to DSA, UAPI)?
> > >
> > > ETH_P_EDSA has a well defined meaning. It is a true global EtherType,
> > > and means a Marvell EtherType DSA header follows.
> > >
> > > You are polluting this meaning of ETH_P_EDSA. Would you put ETH_P_IP
> > > or ETH_P_8021AD here?
> > >
> > >    Andrew
> >
> > You are putting an equality sign here between things that are not quite equal.
> > The MEDSA EtherType is used for the same purpose as what I'm using it for.
>
> I don't think it is. tcpdump will match on this EtherType and decode
> what follows as an EDSA header, just in the same way it matches a
> ETH_P_IP and decodes what comes next as an IP packet. I also have
> wireshark patches, which i never submitted, which do the same.
>
> Please run tcpdump on the master interface with your test system and
> see what it does.
>
>     Andrew

It fails to decode the frames, obviously. But so does any other EtherType.
Florian was hinting
(https://lwn.net/ml/netdev/b52f4cdf-edcf-0757-1d6e-d4a831ec7943@gmail.com/)
at the recent pull requests submitted to tcpdump and libpcap that make
it possible to decode based on the string in
/sys/class/net/${master}/dsa/tagging. I admit I haven't actually
tested or studied those closely yet (there are more important things
to focus on ATM), but since my driver returns "8021q" in sysfs and
yours returns "edsa", I would presume tcpdump could use that
information. Anyway, since you obviously know more on this topic than
I do, please make me understand what are the real problems in spoofing
the Ethertype as a Marvell one.

Thanks,
-Vladimir