netdev - Re: IPv6 UFO for VMs

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: <1413970541.2337.16.camel@localhost>
Date:	Wed, 22 Oct 2014 11:35:41 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	netdev <netdev@...r.kernel.org>,
	virtualization@...ts.linux-foundation.org
Subject: Re: IPv6 UFO for VMs

On Mi, 2014-10-22 at 00:44 +0100, Ben Hutchings wrote:
> There are several ways that VMs can take advantage of UFO and get the
> host to do fragmentation for them:
> 
> drivers/net/macvtap.c:                  gso_type = SKB_GSO_UDP;
> drivers/net/tun.c:                      skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
> drivers/net/virtio_net.c:                       skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
> 
> Our implementation of UFO for IPv6 does:
> 
> 		fptr = (struct frag_hdr *)(skb_network_header(skb) + unfrag_ip6hlen);
> 		fptr->nexthdr = nexthdr;
> 		fptr->reserved = 0;
> 		fptr->identification = skb_shinfo(skb)->ip6_frag_id;
> 
> which assumes ip6_frag_id has been set.  That's only true if the local
> stack constructed the skb; otherwise it appears we get zero.
> 
> This seems to be a regression as a result of:
> 
> commit 916e4cf46d0204806c062c8c6c4d1f633852c5b6
> Author: Hannes Frederic Sowa <hannes@...essinduktion.org>
> Date:   Fri Feb 21 02:55:35 2014 +0100
> 
>     ipv6: reuse ip6_frag_id from ip6_ufo_append_data
> 
> However, that change seems reasonable - we *shouldn't* be choosing IDs
> for any other stack.  Any paravirt net driver that can use IPv6 UFO
> needs to have some way of passing a fragmentation ID to put in
> skb_shared_info::ip6_frag_id.

Do we really gain a lot of performance by enabling UFO on those devices
or would it make sense to just drop support? It only helps fragmenting
large UDP packets, so I don't think it is worth it.

Otherwise I agree with Ben, we need to pass a fragmentation id from the
host over to the system segmenting the gso frame. Fragmentation ids must
be generated by the end system.

Hmm...

Bye,
Hannes


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html