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

[Eric Blake]

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)
>   
>       if (s->flags & DIRTY_BITMAP_MIG_FLAG_ZEROES) {
>           trace_dirty_bitmap_load_bits_zeroes();
> -        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 
> other
> +         * hand, we shouldn't blindly g_malloc the number from the stream.
> +         * Actually one chunk should not be larger thatn CHUNK_SIZE. Let's 
> allow

than

> +         * 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