netdev - Re: [net-next PATCH v2 0/8] UDP GSO Segmentation clean-ups

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]

Date:   Wed, 9 May 2018 08:58:43 -0700
From:   Alexander Duyck <alexander.duyck@...il.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        Willem de Bruijn <willemb@...gle.com>,
        David Miller <davem@...emloft.net>
Subject: Re: [net-next PATCH v2 0/8] UDP GSO Segmentation clean-ups

On Wed, May 9, 2018 at 8:39 AM, Willem de Bruijn
<willemdebruijn.kernel@...il.com> wrote:
> On Mon, May 7, 2018 at 2:02 PM, Alexander Duyck
> <alexander.duyck@...il.com> wrote:
>> On Sat, May 5, 2018 at 3:06 AM, Willem de Bruijn
>> <willemdebruijn.kernel@...il.com> wrote:
>>> On Fri, May 4, 2018 at 8:28 PM, Alexander Duyck
>>> <alexander.duyck@...il.com> wrote:
>>>> This patch set addresses a number of issues I found while sorting out
>>>> enabling UDP GSO Segmentation support for ixgbe/ixgbevf. Specifically there
>>>> were a number of issues related to the checksum and such that seemed to
>>>> cause either minor irregularities or kernel panics in the case of the
>>>> offload request being allowed to traverse between name spaces.
>>>
>>> Were you able to traverse GSO packets between network namespace before
>>> adding to NETIF_F_GSO_SOFTWARE? It does appear that veth includes
>>> NETIF_F_GSO_ENCAP_ALL, which also allows GSO.
>>
>> Without that change the tunnel wouldn't pass the requests between
>> namespaces. However with it I was able to easily test the software
>> checksum code as otherwise the socket was returning EIO when the
>> hardware checksum was disabled.
>>
>>> In either case, it should not be possible for GSO packets to arrive on a veth
>>> device, as that can result in queuing the GSO packet to a recipient socket.
>>> In this regard veth is like loopback and must exclude GSO support.
>>>
>>> I'll take a look.
>>
>> I suspect it was probably sending veth UDP segmentation offload
>> requests. For now I can probably drop he patch that was adding it and
>> it can be added later to individual drivers if needed.
>
> I just tested udpgso_bench_tx over veth (on a commit without your
> patchset).
>
> Having NETIF_F_GSO_UDP_L4 in NETIF_F_GSO_ENCAP_ALL
> and NETIF_F_GSO_ENCAP_ALL in VETH_FEATURES is
> sufficient to receive large packets on the veth peer.
>
> This is clearly a bug, as is for any device that may loop packets
> onto a local socket. Such as macvlan in bridge mode.
>
> I will have to revise commit 83aa025f535f ("udp: add gso support
> to virtual devices")
>
> It remains useful to have this capability on the bonding device. I
> might remove the flag from NETIF_F_GSO_ENCAP_ALL and add
> it specifically to that device.
>
> This is also all relevant to future work of NETIF_F_GSO_SOFTWARE.

Sounds like a plan. In the meantime I am going to see about getting
some internal paperwork taken care of to get UDP GSO added to
ixgbe/ixgbevf as an official feature.

I need to finish up some work I am doing on macvlan over the next
couple of weeks so I won't be focusing on this code for the next month
or so.

Thanks.

- Alex