netdev - Re: [net-next PATCH] IPv6: Use a 16 bit length field when computing a IPv6 UDP checksum

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]

Message-ID: <CAKgT0UdNJLmNqpYir0mNkS560zwc7UJU1ciiTPNU3JfoQNWB2A@mail.gmail.com>
Date:	Tue, 1 Mar 2016 14:26:36 -0800
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	Alex Duyck <aduyck@...antis.com>, Netdev <netdev@...r.kernel.org>
Subject: Re: [net-next PATCH] IPv6: Use a 16 bit length field when computing a
 IPv6 UDP checksum

On Tue, Mar 1, 2016 at 1:35 PM, David Miller <davem@...emloft.net> wrote:
> From: Alexander Duyck <alexander.duyck@...il.com>
> Date: Tue, 1 Mar 2016 13:19:28 -0800
>
>> I was wondering what your thoughts would be about widening the size of
>> the length field that we pass into csum_tcpudp_magic from a 16 bit to
>> a 24 or 32 bit value?  The general idea would be to shift tunnels over
>> to uniformly using skb->len instead of a mix of 16 bit or 32 bit
>> lengths.  My thought is it might add a bit of security since it would
>> invalidate the outer header checksum for the case where length has
>> exceeded 65535 resulting in uh->len field being invalid anyway.
>
> Hmmm, but wait, what is uh->len supposed to be for an ipv6 jumbogram
> anyways?

In a true UDP jumbogram the value for uh->len and ipv6->paylen should
be 0 and the length should be derived based on the actual payload
length which is placed in an IPv6 hop-by-hop extension header with a
jumbo payload option present since paylen is only a 16 bit field in
the IPv6 header.

> It just gets truncated and the the ipv6 header payload length field
> trumps whatever is in the UDP header length field right?

Right.  The RFC 2675 says the value for uh->len should be set to 0 and
instead the total payload length should be used.

> If that's what happens then we should uniformly use the truncated
> length for the pseudo-header calculations as you originally suggested.
>
> How UDP jumbograms as supposed to be handled wrt. udp_hdr->len should
> guide our implementation.

That is kind of what I was thinking.  The only problem is I also have
to sort out IPv4 and IPv6 and hopefully do so in such a way that I
don't end up having to impact the drivers too much.  That is why I was
wondering if we could look at widening out the approach so that it
could be applied to IPv4 as well as IPv6.

One other thought I am having is that maybe I should take a look at
the true scope of this.  For example I know Windows allows for doing
TSO with frames larger than 64K.  Should we maybe start looking at
supporting something like that as well for GRO/GSO?

- Alex