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, 8 Nov 2022 11:00:39 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Felix Fietkau <nbd@....name>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/14] net: vlan: remove invalid VLAN protocol warning

On Tue, Nov 08, 2022 at 07:08:46AM +0100, Felix Fietkau wrote:
> On 07.11.22 22:57, Vladimir Oltean wrote:
> > Aren't you calling __vlan_hwaccel_put_tag() with the wrong thing (i.e.
> > htons(RX_DMA_VPID()) as opposed to VPID translated to something
> > digestible by the rest of the network stack.. ETH_P_8021Q, ETH_P_8021AD
> > etc)?
> 
> The MTK ethernet hardware treats the DSA special tag as a VLAN tag and
> reports it as such. The ethernet driver passes this on as a hwaccel tag, and
> the MTK DSA tag parser consumes it. The only thing that's sitting in the
> middle looking at the tag is the VLAN device lookup with that warning.
> 
> Whenever DSA is not being used, the MTK ethernet device can also process
> regular VLAN tags. For those tags, htons(RX_DMA_VPID()) will contain the
> correct VPID.

So I don't object to the overall theme of having the DSA master offload
the parsing and removal of the DSA tag, but you knock down a bit too
many fences if you carry the DSA tag in skb->vlan_present (not only VLAN
upper device lookup, but also the flow dissector).

What other information will be present in the offloaded DSA headers
except source port information? Maxime Chevallier is also working on a
similar problem for qca8k, except in that case, the RX DSA offload seems
to not be optional for him.

https://patchwork.kernel.org/project/netdevbpf/patch/20221104174151.439008-4-maxime.chevallier@bootlin.com/

Would a solution based on METADATA_HW_PORT_MUX and dst_metadata that
point to refcounted, preallocated structs work for Mediatek SoCs with
DSA, or would more information be necessary?

Meaning: mtk_eth_soc attaches the dst_metadata to the skb, tag_mtk.c
retrieves and removes it.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ