netdev - Re: [net 1/4] net/mlx5e: Force CHECKSUM_UNNECESSARY for short ethernet frames

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]

Date:   Fri, 25 Jan 2019 10:31:17 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Saeed Mahameed <saeedm@...lanox.com>,
        "xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>
Cc:     "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Tariq Toukan <tariqt@...lanox.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "nikola.ciprich@...uxbox.cz" <nikola.ciprich@...uxbox.cz>
Subject: Re: [net 1/4] net/mlx5e: Force CHECKSUM_UNNECESSARY for short
 ethernet frames



On 01/25/2019 10:22 AM, Saeed Mahameed wrote:
> On Tue, 2019-01-22 at 13:30 -0800, Cong Wang wrote:
>> On Fri, Jan 18, 2019 at 4:25 PM Saeed Mahameed <saeedm@...lanox.com>
>> wrote:
>>> From: Cong Wang <xiyou.wangcong@...il.com>
>>
>> I don't know why you want to make me as the author here, but I never
>> agree on _your_ updates on my previous patch.
>>
>> Please see below.
>>
> 
> sorry, i just took your patch and worked on top of it, i thought you
> would like to get the credit for this.
>

I thought the issue was that the hardware csum provided by both mlx4 and mlx5 only
 covered the bytes included in the IP (v4 or v6) frame.

Meaning that any non zero padding bytes are not checksummed.

If this can not be fixed by a firmware change, then the fix has nothing to do with a frame being
smaller than ETH_ZLEN + ETH_FCS_LEN

Alternative would be for the driver to trim the frame (pretend the skb->len is exactly the expected one),
but one could argue that tcpdump should be able to see padding bytes.