netdev - Re: [net PATCH 1/2] net: Disable segmentation if checksumming is not supported

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:	Mon, 2 May 2016 10:20:13 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Tom Herbert <tom@...bertland.com>
Cc:	Alexander Duyck <aduyck@...antis.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [net PATCH 1/2] net: Disable segmentation if checksumming is not supported

On Mon, May 2, 2016 at 10:07 AM, Tom Herbert <tom@...bertland.com> wrote:
> On Mon, May 2, 2016 at 9:48 AM, Alexander Duyck
> <alexander.duyck@...il.com> wrote:
>> On Mon, May 2, 2016 at 9:33 AM, Tom Herbert <tom@...bertland.com> wrote:
>>> On Mon, May 2, 2016 at 9:25 AM, Alexander Duyck <aduyck@...antis.com> wrote:
>>>> In the case of the mlx4 and mlx5 driver they do not support IPv6 checksum
>>>> offload for tunnels.  With this being the case we should disable GSO in
>>>> addition to the checksum offload features when we find that a device cannot
>>>> perform a checksum on a given packet type.
>>>>
>>> I'm not sure I understand this. If device can't support checksum
>>> offload for tunnels doesn't that mean we have to do the checksum on
>>> host regardless of whether GSO is being done?
>>
>> The use of the term GSO here might be the confusing part.  Basically
>> the issue is the hardware advertises it can do TSO for IPv4 on
>> encapsulated frames, however it doesn't indicate it can do IPv6
>> checksum offload.  So what ends up happening is that in the case of a
>> v4 over v6 tunnel we were going through validate_xmit_skb which will
>> check things in netif_skb_features and come out supporting the TSO but
>> no checksums.  As a result we would fall through and hit
>> skb_checksum_help and trigger the warn on in there because we had TSO
>> requested even though we couldn't do the checksum.
>>
>> Basically I am just extending the kind of logic we have in
>> netdev_fix_features so that if we cannot support checksumming the
>> frame then we cannot support segmenting it.
>>
> Thanks for the explanation. We need to drive things so that all the
> encapsulation combinations (v4/v4, v4/v6, v6/v4, v6/v6) are supported
> by HW TSO if any of them are supported by a device. Maybe we should
> still have some sort of warning message that HW is broken for some
> combination (like it apparently it is for mlnx4)?

The problem is the user could end up switching features on/off via
ethtool to create the same kind of situation.  Generally the v4/v6 mix
and match is going to be a more difficult case to deal with.  By
adding the check to the VXLAN features check and updating the checksum
check to disable GSO I think we should have most if not all cases
covered.

Also as far as the mlx4 the Mellanox guys are looking into it because
they were sure the part is supposed to be able to support an outer
IPv6 header so we may see something int he future come out to address
that.  Really what I would like to see us get away from is having
hardware to do any tunnel parsing for Tx which is where I believe this
issue lies since on the Rx side the mlx4 doesn't seem to recognize
tunnels encapsulated in IPv6 since it doesn't perform an inner
checksum offload.

- Alex