| 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
| ||
|
Message-ID: <YSLJervLt/xNIKHn@lunn.ch>
Date: Mon, 23 Aug 2021 00:02:34 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Alvin Šipraga <alvin@...s.dk>
Cc: Linus Walleij <linus.walleij@...aro.org>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>, mir@...g-olufsen.dk,
Alvin Šipraga <alsi@...g-olufsen.dk>,
netdev@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH net-next 3/5] net: dsa: tag_rtl8_4: add realtek 8
byte protocol 4 tag
On Sun, Aug 22, 2021 at 09:31:41PM +0200, Alvin Šipraga wrote:
> diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
> index 548285539752..470a2f3e8f75 100644
> --- a/net/dsa/Kconfig
> +++ b/net/dsa/Kconfig
> @@ -99,6 +99,12 @@ config NET_DSA_TAG_RTL4_A
> Realtek switches with 4 byte protocol A tags, sich as found in
> the Realtek RTL8366RB.
>
> +config NET_DSA_TAG_RTL8_4
> + tristate "Tag driver for Realtek 8 byte protocol 4 tags"
> + help
> + Say Y or M if you want to enable support for tagging frames for Realtek
> + switches with 8 byte protocol 4 tags, such as the Realtek RTL8365MB-VC.
> +
Hi Alvin
This file is sorted based on the tristate text. As such, the
NET_DSA_TAG_RTL4_A is in the wrong place. So i can understand why you
put it here, but place move it after the Qualcom driver.
> @@ -11,6 +11,7 @@ obj-$(CONFIG_NET_DSA_TAG_GSWIP) += tag_gswip.o
> obj-$(CONFIG_NET_DSA_TAG_HELLCREEK) += tag_hellcreek.o
> obj-$(CONFIG_NET_DSA_TAG_KSZ) += tag_ksz.o
> obj-$(CONFIG_NET_DSA_TAG_RTL4_A) += tag_rtl4_a.o
> +obj-$(CONFIG_NET_DSA_TAG_RTL8_4) += tag_rtl8_4.o
> obj-$(CONFIG_NET_DSA_TAG_LAN9303) += tag_lan9303.o
> obj-$(CONFIG_NET_DSA_TAG_MTK) += tag_mtk.o
> obj-$(CONFIG_NET_DSA_TAG_OCELOT) += tag_ocelot.o
The CONFIG_NET_DSA_TAG_RTL4_A is also in the wrong place...
> diff --git a/net/dsa/tag_rtl8_4.c b/net/dsa/tag_rtl8_4.c
> new file mode 100644
> index 000000000000..1082bafb6a2e
> --- /dev/null
> +++ b/net/dsa/tag_rtl8_4.c
> @@ -0,0 +1,178 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Handler for Realtek 8 byte switch tags
> + *
> + * Copyright (C) 2021 Alvin Šipraga <alsi@...g-olufsen.dk>
> + *
> + * NOTE: Currently only supports protocol "4" found in the RTL8365MB, hence
> + * named tag_rtl8_4.
> + *
> + * This "proprietary tag" header has the following format:
I think they are all proprietary. At least, there is no
standardization across vendors.
> + *
> + * -------------------------------------------
> + * | MAC DA | MAC SA | 8 byte tag | Type | ...
> + * -------------------------------------------
> + * _______________/ \______________________________________
> + * / \
> + * 0 7|8 15
> + * |-----------------------------------+-----------------------------------|---
> + * | (16-bit) | ^
> + * | Realtek EtherType [0x8899] | |
> + * |-----------------------------------+-----------------------------------| 8
> + * | (8-bit) | (8-bit) |
> + * | Protocol [0x04] | REASON | b
> + * |-----------------------------------+-----------------------------------| y
> + * | (1) | (1) | (2) | (1) | (3) | (1) | (1) | (1) | (5) | t
> + * | FID_EN | X | FID | PRI_EN | PRI | KEEP | X | LEARN_DIS | X | e
> + * |-----------------------------------+-----------------------------------| s
> + * | (1) | (15-bit) | |
> + * | ALLOW | TX/RX | v
> + * |-----------------------------------+-----------------------------------|---
> + *
> + * With the following field descriptions:
> + *
> + * field | description
> + * ------------+-------------
> + * Realtek | 0x8899: indicates that this is a proprietary Realtek tag;
> + * EtherType | note that Realtek uses the same EtherType for
> + * | other incompatible tag formats (e.g. tag_rtl4_a.c)
> + * Protocol | 0x04: indicates that this tag conforms to this format
> + * X | reserved
> + * ------------+-------------
> + * REASON | reason for forwarding packet to CPU
Are you allowed to document reason? This could be interesting for some
of the future work.
> + * FID_EN | 1: packet has an FID
> + * | 0: no FID
> + * FID | FID of packet (if FID_EN=1)
> + * PRI_EN | 1: force priority of packet
> + * | 0: don't force priority
> + * PRI | priority of packet (if PRI_EN=1)
> + * KEEP | preserve packet VLAN tag format
> + * LEARN_DIS | don't learn the source MAC address of the packet
> + * ALLOW | 1: treat TX/RX field as an allowance port mask, meaning the
> + * | packet may only be forwarded to ports specified in the
> + * | mask
> + * | 0: no allowance port mask, TX/RX field is the forwarding
> + * | port mask
> + * TX/RX | TX (switch->CPU): port number the packet was received on
> + * | RX (CPU->switch): forwarding port mask (if ALLOW=0)
> + * | allowance port mask (if ALLOW=1)
There are some interesting fields here. It will be interesting to see
what we can do with the switch.
> + */
> +
> +#include <linux/etherdevice.h>
> +#include <linux/bits.h>
> +
> +#include "dsa_priv.h"
> +
> +#define RTL8_4_TAG_LEN 8
> +#define RTL8_4_ETHERTYPE 0x8899
Please add this to include/uapi/linux/if_ether.h
> +static struct sk_buff *rtl8_4_tag_rcv(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + __be16 *p;
> + u16 etype;
> + u8 proto;
> + u8 *tag;
> + u8 port;
> + u16 tmp;
> +
> + if (unlikely(!pskb_may_pull(skb, RTL8_4_TAG_LEN)))
> + return NULL;
> +
> + tag = dsa_etype_header_pos_rx(skb);
> +
> + /* Parse Realtek EtherType */
> + p = (__be16 *)tag;
> + etype = ntohs(*p);
> + if (unlikely(etype != RTL8_4_ETHERTYPE)) {
> + netdev_dbg(dev, "non-realtek ethertype 0x%04x\n", etype);
You probably want to rate limit these sorts of prints. You have
limited controller of what frames come in, and if somebody can craft
bad frames, they can make you send all your time printing messages to
the log.
Andrew
Powered by blists - more mailing lists