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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAF=yD-+=9EUjiT=ZG+G=phQcHmD8s3e6mydhBehddVCqL0pEGg@mail.gmail.com>
Date:   Wed, 9 May 2018 11:39:37 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Alexander Duyck <alexander.duyck@...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 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.