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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210405160339.1c264af4@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 5 Apr 2021 16:03:39 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Julian Labus <julian@...ifunk-rtk.de>, 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

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.