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

[Anton Nayshtut]

Hi all,

All relevant tests passed with the Ben's patch as well.

Thus, it does suffice.

Best Regards,
Anton

On Mon, Jun 23, 2014 at 7:52 PM, Anton Nayshtut <anton at swortex.com> wrote:
> Hi Tim and Luis,
>
> We're testing the patch backported by Ben Hutching right now.
>
> Will update you once the tests are done.
>
> Best Regards,
> Anton
>
> On Mon, Jun 23, 2014 at 5:06 PM, Tim Gardner <tim.gardner at canonical.com> wrote:
>> 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