[Saucy] [PATCH] SRU: zerocopy LSO segmenting fixed

[Tim Gardner]

On 06/23/2014 07:53 AM, Luis Henriques wrote:
> On Sun, Jun 22, 2014 at 11:07:42AM +0300, Anton Nayshtut wrote:
>> BugLink: https://bugs.launchpad.net/bugs/1328973
>>
>> [SRU Justification]
>>
>> [Setup]
>>   - 2 or more QEMU Guest VMs sharing the the same host
>>   - the Guests are communicating using virtio-net-pci devices
>>   - vhost-net is enabled
>>
>> [Explanation]
>> If one Guest VM sends GSO packets to another while GRO is disabled for receiver,
>> so these packets are segmented by net/core.
>> In this case, if zero-copy is enabled in vhost-net, the GSO packets TX
>> completion is reported to userspace as before the TX is actually done.
>> The vhost-net's zero-copy mechanism is enabled by default since v3.8-rc1
>> (f9611c43).
>>
>> [Impact]
>> Incorrect/junk data sent in case the transmitting Guest OS re-uses/frees the TX
>> buffer immediately upon TX completion.
>>
>> [Test Case]
>> Windows 2008R2 Guest VMs running MS HCK Offload LSO test.
>> NOTE1: GRO is always disabled in this case because it's not supported by Windows
>> Guest virtio-net-pci drivers.
>> NOTE2: MS HCK re-uses the GSO (LSO) buffers, so it reproduces the issue every
>> time.
>>
>>     skbuff: skb_segment: orphan frags before copying
>>
>>      skb_segment copies frags around, so we need
>>      to copy them carefully to avoid accessing
>>      user memory after reporting completion to userspace
>>      through a callback.
>>
>>      skb_segment doesn't normally happen on datapath:
>>      TSO needs to be disabled - so disabling zero copy
>>      in this case does not look like a big deal.
>>
>>      OriginalAuthor: Michael S. Tsirkin <mst at redhat.com>
>>      Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
>>      Acked-by: Herbert Xu <herbert at gondor.apana.org.au>
>>      Signed-off-by: David S. Miller <davem at davemloft.net>
>>
>>      (cherry picked from commit 1fd819ecb90cc9b822cd84d3056ddba315d3340f)
>>      CVE-2014-0131
>>      Signed-off-by: Andy Whitcroft <apw at canonical.com>
>>      (backported from 0f860fb4f583909ed999df58abf57ff40ec94d6d ubuntu-trusty)
>>      Signed-off-by: Anton Nayshtut <anton at swortex.com>
>>
>
> This patch is included in the 3.11 extended stable currently under
> review[1].  Since Saucy picks the 3.11 extended stable releases, this
> patch would be included in the Saucy kernel anyway (Note:
> lts-backport-saucy kernels are about to reach EOL!).
>
> However, the backport is I have for the 3.11 kernel is different[2]
> from this one and I am not able to decide which is correct one.
>
> For the 3.11 kernel I have picked the version provided by Ben Hutching
> to the stable mailing list[3].  This version is currently being used
> in the Lucid kernel, and has been released on the 3.8 extended
> stable.
>
> [1] https://lkml.org/lkml/2014/6/23/368
> [2] https://lkml.org/lkml/2014/6/23/400
> [3] http://thread.gmane.org/gmane.linux.kernel.stable/93422
>
> Cheers,
> --
> Luís
>

There does seem to be a small, but fundamental, difference.

Anton - could you have a look to see if the upstream patch will suffice 
? I'd prefer to go with what is coming up in stable because its been 
tested in Lucid.

rtg
-- 
Tim Gardner tim.gardner at canonical.com