netdev - Re: regression: UFO removal breaks kvm live migration

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 8 Nov 2017 17:25:48 +0900
From:   Jason Wang <jasowang@...hat.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:     David Miller <davem@...emloft.net>,
        Michal Kubecek <mkubecek@...e.cz>,
        Network Development <netdev@...r.kernel.org>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Vlad Yasevic <vyasevic@...hat.com>
Subject: Re: regression: UFO removal breaks kvm live migration



On 2017年11月08日 17:08, Willem de Bruijn wrote:
> On Wed, Nov 8, 2017 at 4:49 PM, Jason Wang <jasowang@...hat.com> wrote:
>>
>> On 2017年11月08日 15:26, David Miller wrote:
>>> From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
>>> Date: Wed, 8 Nov 2017 12:36:26 +0900
>>>
>>>> On Tue, Nov 7, 2017 at 5:02 PM, Michal Kubecek <mkubecek@...e.cz> wrote:
>>>>> I didn't have time to think it through yet but perhaps we could allow
>>>>> setting TUN_F_UFO and ignore its value.
>>>> If the feature is enabled guests may try to send UFO packets, which
>>>> the host is no longer able to fragment.
>>>>
>>>> virtio_net_hdr_to_skb will drop the packets immediately based on
>>>> gso_type and tun_get_user will return EINVAL.
>>>>
>>>> Still, perhaps that's preferable as migration will succeed and most
>>>> guests won't ever try to send those packets in the first place.
>>> However, this would create the situation where there is no way
>>> to properly probe for the actual presence of UFO support.
>>
>> I think we should not have any assumption on how guest will use the feature.
>> So I could not come a better than bring it back partially for TAP, looks
>> like we only need segment them in tun_get_user().
> Live migration essentially expects that features can never be removed [1],
> as feature bits are not renegotiated after migration. In the short term we'll
> have to work around that, but in the long term that does not seem practical.
>
> There already exist interfaces to renegotiate guest/host state at runtime,
> including for offloads [2][3]. For newer guests, we should support a trigger
> from the host to renegotiate offloads.

I could not think of a real use case for this other than trying to 
workaround a bug.

>
> That won't help in the short term. I'm still reading up to see if there are
> any other options besides reimplement or advertise-but-drop, such as
> an implicit trigger that would make the guest renegotiate. It's unlikely, but
> worth a look..

Yes, this looks hard. And even if we can manage to do this, it looks an 
overkill since it will impact all guest after migration.

Thanks

>
> [1] https://lists.linuxfoundation.org/pipermail/virtualization/2014-November/028126.html
> [2] https://lists.linuxfoundation.org/pipermail/virtualization/2013-April/023818.html
> [3] https://patchwork.kernel.org/patch/9850785/