All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: guangrong.xiao@gmail.com, pbonzini@redhat.com, mst@redhat.com,
	mtosatti@redhat.com
Cc: kvm@vger.kernel.org, Xiao Guangrong <xiaoguangrong@tencent.com>,
	qemu-devel@nongnu.org, peterx@redhat.com, dgilbert@redhat.com,
	wei.w.wang@intel.com, jiang.biao2@zte.com.cn
Subject: Re: [PATCH] migration: introduce decompress-error-check
Date: Thu, 26 Apr 2018 09:01:22 -0500	[thread overview]
Message-ID: <32eaad8e-35a0-5240-37a2-4242b7890ab9@redhat.com> (raw)
In-Reply-To: <20180426091519.26934-1-xiaoguangrong@tencent.com>

[-- Attachment #1: Type: text/plain, Size: 2778 bytes --]

On 04/26/2018 04:15 AM, guangrong.xiao@gmail.com wrote:
> From: Xiao Guangrong <xiaoguangrong@tencent.com>
> 
> QEMU 2.13 enables strict check for compression & decompression to
> make the migration more robuster, that depends on the source to fix

s/robuster/robust/

> the internal design which triggers the unexpected error conditions

2.13 hasn't been released yet.  Why do we need a knob to explicitly turn
off strict checking?  Can we not instead make 2.13 automatically smart
enough to tell if the incoming stream is coming from an older qemu
(which might fail if the strict checks are enabled) vs. a newer qemu
(the sender gave us what we need to ensure the strict checks are
worthwhile)?

> 
> To make it work for migrating old version QEMU to 2.13 QEMU, we
> introduce this parameter to disable the error check on the
> destination
> 
> Signed-off-by: Xiao Guangrong <xiaoguangrong@tencent.com>
> ---

> +++ b/qapi/migration.json
> @@ -455,6 +455,17 @@
>  #          compression, so set the decompress-threads to the number about 1/4
>  #          of compress-threads is adequate.
>  #
> +# @decompress-error-check: check decompression errors. When false, the errors
> +#                          triggered by memory decompression are ignored.

What are the consequences of such an error?  Is it a security hole to
leave this at false, when a malicious migration stream can cause us to
misbehave by ignoring the errors?

> +#                          When true, migration is aborted if the errors are
> +#                          detected. For the old QEMU versions (< 2.13) the
> +#                          internal design will cause decompression to fail
> +#                          so the destination should completely ignore the
> +#                          error conditions, i.e, make it be false if these
> +#                          QEMUs are going to be migrated. Since 2.13, this
> +#                          design is fixed, make it be true to avoid corrupting
> +#                          the VM silently (Since 2.13)

Rather wordy; I'd suggest:

@decompress-error-check: Set to true to abort the migration if
        decompression errors are detected at the destination. Should be
        left at false (default) for qemu older than 2.13, since only
        newer qemu sends streams that do not trigger spurious
        decompression errors. (Since 2.13)

But that's if we even need it (it SHOULD be possible to design something
into the migration stream so that you can detect this property
automatically instead of relying on the user to set the property).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

WARNING: multiple messages have this Message-ID
From: Eric Blake <eblake@redhat.com>
To: guangrong.xiao@gmail.com, pbonzini@redhat.com, mst@redhat.com,
	mtosatti@redhat.com
Cc: kvm@vger.kernel.org, Xiao Guangrong <xiaoguangrong@tencent.com>,
	qemu-devel@nongnu.org, peterx@redhat.com, dgilbert@redhat.com,
	wei.w.wang@intel.com, jiang.biao2@zte.com.cn
Subject: Re: [Qemu-devel] [PATCH] migration: introduce decompress-error-check
Date: Thu, 26 Apr 2018 09:01:22 -0500	[thread overview]
Message-ID: <32eaad8e-35a0-5240-37a2-4242b7890ab9@redhat.com> (raw)
In-Reply-To: <20180426091519.26934-1-xiaoguangrong@tencent.com>

[-- Attachment #1: Type: text/plain, Size: 2778 bytes --]

On 04/26/2018 04:15 AM, guangrong.xiao@gmail.com wrote:
> From: Xiao Guangrong <xiaoguangrong@tencent.com>
> 
> QEMU 2.13 enables strict check for compression & decompression to
> make the migration more robuster, that depends on the source to fix

s/robuster/robust/

> the internal design which triggers the unexpected error conditions

2.13 hasn't been released yet.  Why do we need a knob to explicitly turn
off strict checking?  Can we not instead make 2.13 automatically smart
enough to tell if the incoming stream is coming from an older qemu
(which might fail if the strict checks are enabled) vs. a newer qemu
(the sender gave us what we need to ensure the strict checks are
worthwhile)?

> 
> To make it work for migrating old version QEMU to 2.13 QEMU, we
> introduce this parameter to disable the error check on the
> destination
> 
> Signed-off-by: Xiao Guangrong <xiaoguangrong@tencent.com>
> ---

> +++ b/qapi/migration.json
> @@ -455,6 +455,17 @@
>  #          compression, so set the decompress-threads to the number about 1/4
>  #          of compress-threads is adequate.
>  #
> +# @decompress-error-check: check decompression errors. When false, the errors
> +#                          triggered by memory decompression are ignored.

What are the consequences of such an error?  Is it a security hole to
leave this at false, when a malicious migration stream can cause us to
misbehave by ignoring the errors?

> +#                          When true, migration is aborted if the errors are
> +#                          detected. For the old QEMU versions (< 2.13) the
> +#                          internal design will cause decompression to fail
> +#                          so the destination should completely ignore the
> +#                          error conditions, i.e, make it be false if these
> +#                          QEMUs are going to be migrated. Since 2.13, this
> +#                          design is fixed, make it be true to avoid corrupting
> +#                          the VM silently (Since 2.13)

Rather wordy; I'd suggest:

@decompress-error-check: Set to true to abort the migration if
        decompression errors are detected at the destination. Should be
        left at false (default) for qemu older than 2.13, since only
        newer qemu sends streams that do not trigger spurious
        decompression errors. (Since 2.13)

But that's if we even need it (it SHOULD be possible to design something
into the migration stream so that you can detect this property
automatically instead of relying on the user to set the property).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

  parent reply	other threads:[~2018-04-26 14:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26  9:15 [PATCH] migration: introduce decompress-error-check guangrong.xiao
2018-04-26  9:15 ` [Qemu-devel] " guangrong.xiao
2018-04-26  9:19 ` Xiao Guangrong
2018-04-26  9:19   ` [Qemu-devel] " Xiao Guangrong
2018-04-26  9:34 ` Dr. David Alan Gilbert
2018-04-26  9:34   ` [Qemu-devel] " Dr. David Alan Gilbert
2018-04-26 13:18   ` Xiao Guangrong
2018-04-26 13:18     ` [Qemu-devel] " Xiao Guangrong
2018-04-26 14:01 ` Eric Blake [this message]
2018-04-26 14:01   ` Eric Blake
2018-04-27  3:15   ` Xiao Guangrong
2018-04-27  3:15     ` [Qemu-devel] " Xiao Guangrong
2018-04-27  9:31     ` Peter Xu
2018-04-27  9:31       ` [Qemu-devel] " Peter Xu
2018-04-27 10:40       ` Xiao Guangrong
2018-04-27 10:40         ` [Qemu-devel] " Xiao Guangrong
2018-05-02  3:03         ` Peter Xu
2018-05-02  3:03           ` [Qemu-devel] " Peter Xu
2018-05-02 14:57           ` Dr. David Alan Gilbert
2018-05-02 14:57             ` [Qemu-devel] " Dr. David Alan Gilbert
2018-05-03  2:10             ` Peter Xu
2018-05-03  2:10               ` [Qemu-devel] " Peter Xu
2018-04-27 11:29     ` Dr. David Alan Gilbert
2018-04-27 11:29       ` [Qemu-devel] " Dr. David Alan Gilbert
2018-04-28  6:13       ` Xiao Guangrong
2018-04-28  6:13         ` [Qemu-devel] " Xiao Guangrong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32eaad8e-35a0-5240-37a2-4242b7890ab9@redhat.com \
    --to=eblake@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=guangrong.xiao@gmail.com \
    --cc=jiang.biao2@zte.com.cn \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wei.w.wang@intel.com \
    --cc=xiaoguangrong@tencent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.