netdev - Re: [PATCH v7 net-next 01/16] gso: Remove arbitrary checks for unsupported GSO

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: <CAKgT0Uc9eqYtXB=HVVitF1BWkoVZv8tqppwbQdnhKbfJ-VA_ew@mail.gmail.com>
Date:	Fri, 20 May 2016 20:56:34 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Tom Herbert <tom@...bertland.com>,
	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>,
	Kernel Team <kernel-team@...com>,
	"Michael S. Tsirkin" <mst@...hat.com>
Subject: Re: [PATCH v7 net-next 01/16] gso: Remove arbitrary checks for
 unsupported GSO

On Fri, May 20, 2016 at 6:02 PM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> Hello,
>
> On 18.05.2016 18:06, Tom Herbert wrote:
>> In several gso_segment functions there are checks of gso_type against
>> a seemingly arbitrary list of SKB_GSO_* flags. This seems like an
>> attempt to identify unsupported GSO types, but since the stack is
>> the one that set these GSO types in the first place this seems
>> unnecessary to do. If a combination isn't valid in the first
>> place that stack should not allow setting it.
>>
>> This is a code simplication especially for add new GSO types.
>
> I couldn't still wrap my head around this.
>
> I wonder if this is safe in case of if the packet is generated from an
> untrusted virtual machine over virtio_net?

The problem is the test is kind of pointless.  I think the original
point of the tests was to prevent the case of IPIP and TSO6 or SIT and
TSO4.  However since we dropped IPIP and SIT and instead replaced them
with the IPXIP6 and IPXIP4 there shouldn't be any combinations that
don't work now other than UDP being combined with TCP segmentation.

If we are wanting to prevent that case we might place something
earlier in the segmentation code that would perform an and with all
the L4 GSO types that should be mutually exclusive, verify that value
is non-zero, and then and that value with itself - 1 to verify that
exactly 1 bit is set in that grouping and no more than that.

- Alex