netdev - Re: [PATCH net-next v4 11/11] net: dsa: realtek: rtl8365mb: multiple cpu ports, non cpu extint

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, 25 Jan 2022 19:29:25 -0300
From:   Luiz Angelo Daros de Luca <luizluca@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Frank Wunderlich <frank-w@...lic-files.de>,
        Alvin Šipraga <ALSI@...g-olufsen.dk>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "vivien.didelot@...il.com" <vivien.didelot@...il.com>,
        "arinc.unal@...nc9.com" <arinc.unal@...nc9.com>
Subject: Re: [PATCH net-next v4 11/11] net: dsa: realtek: rtl8365mb: multiple
 cpu ports, non cpu extint

> Could you implement a prototype of packet parsing in ndo_features_check,
> which checks for the known DSA EtherType and clears the offload bit for
> unsupported packets, and do some performance testing before and after,
> to lean the argument in your favor with some numbers? I've no problem if
> you test for the worst case, i.e. line rate with small UDP packets
> encapsulated with the known (offload-capable) DSA tag format, where
> there is little benefit for offloading TX checksumming.

There is no way to tell if a packet has a DSA tag only by parsing its
content. For Realtek and Marvel EDSA, there is a distinct ethertype
(although Marvel EDSA uses a non-registered number) that drivers can
check. For others, specially those that add the tag before the
ethernet header or after the payload, it might not have a magic
number. It is impossible to securely identify if and which DSA is in
use for some DSA tags from the packet alone. This is also the case for
mediatek. Although it places its tag just before ethertype (like
Realtek and Marvel), there is no magic number. It needs some context
to know what type of DSA was applied.

skb_buf today knows nothing about the added DSA tag. Although
net_device does know if it is a master port in a dsa tree, and it has
a default dsa tag, with multiple switches using different tags, it
cannot tell which dsa tag was added to that packet.
That is the information I need to test if that tag is supported or not
by this drive.

I believe once an offload HW can digest a dsa tag, it might support
the same type of protocols with or without the tag.
In the end, what really matters is if a driver supports a specific dsa tag.

Wouldn't it be much easier to have a dedicated optional
ndo_dsa_tag_supported()? It would be only needed for those drivers
that still use NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM and only those that
can digest a tag.

Regards,