netdev - Re: stmmac: zero udp checksum

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: <e68b0973-226d-8223-7d0d-32a865c7af70@freifunk-rtk.de>
Date:   Thu, 20 May 2021 14:18:07 +0200
From:   Julian Labus <julian@...ifunk-rtk.de>
To:     Jakub Kicinski <kuba@...nel.org>, Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, mschiffer@...verse-factory.net,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Jose Abreu <joabreu@...opsys.com>,
        Ong Boon Leong <boon.leong.ong@...el.com>
Subject: Re: stmmac: zero udp checksum

Hi stmmac maintainers,

it's around 1 1/2 months without any response on this topic.
Could you please advice how to proceed with this problem?

Kind regards,
Julian

On 06.04.21 01:03, Jakub Kicinski wrote:
> On Mon, 5 Apr 2021 18:42:53 +0200 Andrew Lunn wrote:
>>> But was is still a bit strange to me is that it seems like the stmmac driver
>>> behaves different than other ethernet drivers which do not drop UDP packets
>>> with zero checksums when rx checksumming is enabled.
>>
>> To answer that, you need somebody with more knowledge of the stmmac
>> hardware.
> 
> +1 stmmac maintainers could you advise?
> 
>> It is actually quite hard to do. It means you need to parse
>> more of the frame to determine if the frame contains a VXLAN
>> encapsulated frame. Probably the stmmac cannot do that. It sees the
>> checksum is wrong and drops the packet.
>>
>> Have you looked at where it actually drops the packet?
>> Is it one of
>>
>> https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/stmicro/stmmac/norm_desc.c#L95
>>
>> or
>>
>> https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/stmicro/stmmac/enh_desc.c#L87
>>
>> It could be, you need to see if the checksum has fail, then check if
>> the checksum is actually zero, and then go deeper into the frame and
>> check if it is a vxlan frame. It could be the linux software checksum
>> code knows about this vxlan exception, so you can just run that before
>> deciding to drop the frame.
> 
> To be clear the expectation is that devices / drivers will only drop
> packets on L2 / FCS errors. If L3 or L4 csum is incorrect the packet
> should be passed up the stack and kernel will handle it how it sees fit.
>