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, 9 Nov 2015 03:23:18 +0100
From:	"Jason A. Donenfeld" <Jason@...c4.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Maciej Żenczykowski <zenczykowski@...il.com>,
	Tom Herbert <tom@...bertland.com>,
	Jiri Benc <jbenc@...hat.com>, Netdev <netdev@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: GSO with udp_tunnel_xmit_skb

On Mon, Nov 9, 2015 at 2:40 AM, Herbert Xu <herbert@...dor.apana.org.au> wrote:
> You're right.  I don't think the ordering matters.

Cool, so we're on the same page then.

In that case, any ideas about constructing UDP super-packets for GSO?
As Maciej pointed out, UFO is actually just IP fragmentation and UDP
checksums, but doesn't actually add on new UDP headers as we'd wish.
But I was digging a bit deeper and I found this gem:
skb_udp_tunnel_segment. This is the segmentation function called for
SKB_GSO_UDP_TUNNEL. For this, it does something sort of neat.

If the skb's inner_protocol_type is ENCAP_TYPE_IPPROTO, then it looks
up an "gso_inner_segment" function based on the skb->inner_ipproto
field. The lookup happens on a list of functions (called
inet6_offloads and inet_offloads) that has some nice setter/getter
methods for various modules to call.

Once it figures out which gso_inner_segment to use, it calls
__skb_udp_tunnel_segment with it, which then does some curious header
calculations on various lengths (that I need to read carefully), and
then proceeds to split the segments using our gso_inner_segment
function of choice, and then adds the length and checksum header
fields. Unfortunately, it doesn't add the UDP source and destination
port header fields. That means I might as well be building the UDP
headers ahead of time myself, which is a bit of a bummer.

Anyway, the idea would be to [ab]use SKB_GSO_UDP_TUNNEL with a
scintillating gso_inner_segment function for a custom inner_ipproto
field, in order to make a superpacket.

How's this looking as a strategy (and an outline of the "niggly bits"
as you put it)?

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists