netdev - Re: [PATCH net 0/1] Prevent DSA tags from breaking COE

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] [day] [month] [year] [list]

Message-ID: <9e371efe-8759-4e4a-bbd6-8ec2a12620a1@electromag.com.au>
Date: Fri, 5 Jan 2024 12:37:42 +0800
From: Richard Tresidder <rtresidd@...ctromag.com.au>
To: Romain Gantois <romain.gantois@...tlin.com>, Andrew Lunn <andrew@...n.ch>
Cc: Alexandre Torgue <alexandre.torgue@...s.st.com>,
  Jose Abreu <joabreu@...opsys.com>, "David S. Miller" <davem@...emloft.net>,
  Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
  Paolo Abeni <pabeni@...hat.com>,
  Maxime Coquelin <mcoquelin.stm32@...il.com>,
  Miquel Raynal <miquel.raynal@...tlin.com>,
  Maxime Chevallier <maxime.chevallier@...tlin.com>,
  Sylvain Girard <sylvain.girard@...com>,
  Pascal EBERHARD <pascal.eberhard@...com>, netdev@...r.kernel.org,
  linux-stm32@...md-mailman.stormreply.com,
  linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH net 0/1] Prevent DSA tags from breaking COE

Richard Tresidder

Hi All
    Just wondering if from a custom platform point of view it might be better to use vlan tagging instead of DSA in the case where the MAC can't handle DSA tags in the header.
The marvel chip can use VLAN tagging to perform basically the same thing is my understanding, you just have to nominate a vlan id (untag outbound) to a port and trunk on cpu interface..
Just considering this as from my understanding the STMMAC does understand VLAN tags and will correctly generate the CRC.
I don't think this would stop us using VLAN for the ports in general, they'd just have a "default" tag for each port thats used for untagged packets on the port.
You could still apply additional VLAN's over those same ports..

I don't suppose anyone has some CPU usage info on software CRC vs this method?
I'm not sure if this is just an IP CRC issue or a TCP CRC issue also ( can the stmmac offload the TCP CRC also? )
If this is only an IP issue and the TCP CRC is never offloaded then it probably won't make much difference in reality..

Thanks
    Richard Tresidder

On 19/12/2023 5:50 pm, Romain Gantois wrote:

> On Mon, 18 Dec 2023, Andrew Lunn wrote:
> ...
>> Probably a dumb question.... Does this COE also perform checksum
>> validation on receive? Is it also getting confused by the DSA header?
>>
>> You must of tested receive, so it works somehow, but i just wounder if
>> something needs to be done to be on the safe side?
> That's a good point, I just investigated the RX path a bit more and the MAC
> indeed has IP/TCP/UDP RX checksum offloading enabled. However, the
> external switch in my setup uses EDSA tags, which displace the "true" ethertype
> field to the end of the DSA header and replaces the "normal" ethertype with
> ETH_P_EDSA (0xdada). So to the MAC controller, the ethernet frame has an unknown
> ethertype, and so it doesn't see it as an IP frame at all. All of the
> ethtool counters related to IP stuff are at 0, which supports this.
>
> This explains why checksum offloading doesn't break the RX path in my case.
> However, other maybe other DSA switches using different frame formats could
> cause different behavior? Considering this, I think it would be safer to change
> the dsa_breaks_tx_coe flag to a general dsa_breaks_coe flag. It makes sense to
> me to assume that if DSA tags break TX COE, then RX COE will also not work.
>
> I'll take this into account when I send a v2.
>
> Best Regards,
>