[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 15/21] migration/block-dirty-bitmap: relax error handling

From: Eric Blake
Subject: Re: [PATCH v4 15/21] migration/block-dirty-bitmap: relax error handling in incoming part
Date: Mon, 27 Jul 2020 15:14:00 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 7/27/20 2:42 PM, Vladimir Sementsov-Ogievskiy wrote:
Bitmaps data is not critical, and we should not fail the migration (or
use postcopy recovering) because of dirty-bitmaps migration failure.
Instead we should just lose unfinished bitmaps.

Still we have to report io stream violation errors, as they affect the
whole migration stream.

I'm amending this to also add:

While touching this, tighten code that was previously blindly calling malloc on a size read from the migration stream, as a corrupted stream (perhaps from a malicious user) should not be able to convince us to allocate an inordinate amount of memory.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
  migration/block-dirty-bitmap.c | 164 +++++++++++++++++++++++++--------
  1 file changed, 127 insertions(+), 37 deletions(-)

@@ -650,15 +695,46 @@ static int dirty_bitmap_load_bits(QEMUFile *f, 
DBMLoadState *s)
-        bdrv_dirty_bitmap_deserialize_zeroes(s->bitmap, first_byte, nr_bytes,
-                                             false);
+        if (!s->cancelled) {
+            bdrv_dirty_bitmap_deserialize_zeroes(s->bitmap, first_byte,
+                                                 nr_bytes, false);
+        }
      } else {
          size_t ret;
-        uint8_t *buf;
+        g_autofree uint8_t *buf = NULL;
          uint64_t buf_size = qemu_get_be64(f);
-        uint64_t needed_size =
-            bdrv_dirty_bitmap_serialization_size(s->bitmap,
-                                                 first_byte, nr_bytes);
+        uint64_t needed_size;
+        /*
+         * Actual check for buf_size is done a bit later. We can't do it in

s/Actual/The actual/

+         * cancelled mode as we don't have the bitmap to check the constraints
+         * (so, we do allocate buffer and read prior to the check). On the 
+         * hand, we shouldn't blindly g_malloc the number from the stream.
+         * Actually one chunk should not be larger thatn CHUNK_SIZE. Let's 


+         * a bit larger (which means that bitmap migration will fail anyway and
+         * the whole migration will most probably fail soon due to broken
+         * stream).
+         */
+        if (buf_size > 10 * CHUNK_SIZE) {
+            error_report("Bitmap migration stream requests too large buffer "
+                         "size to allocate");

Bitmap migration stream buffer allocation request is too large

I'll make those touchups.

Reviewed-by: Eric Blake <eblake@redhat.com>

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]