xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [PATCH 2/4] tools/libxc: Tolerate zero-length records in migration v2 streams
Date: Mon, 25 Jul 2016 13:21:12 +0100	[thread overview]
Message-ID: <57960438.5000208@citrix.com> (raw)
In-Reply-To: <1469121457-365-3-git-send-email-andrew.cooper3@citrix.com>

On 21/07/16 18:17, Andrew Cooper wrote:
> Under some circumstances, the migration v2 save code would generate valid
> records with zero content, when the intended behaviour was to omit the record
                                      ^^^^^^^^
As explained, this is not the intended behaviour.  I would appreciate it
if you did not misrepresent me here.

> entirely.
> 
> As the stream is otherwise fine, tolerate these records and avoid failing the
> migration.
[...]
> --- a/tools/libxc/xc_sr_restore_x86_hvm.c
> +++ b/tools/libxc/xc_sr_restore_x86_hvm.c
[...]
> +    /*
> +     * Tolerate empty records.  Older sending sides used to accidentally
> +     * generate them.
> +     */
> +    if ( hdr->count == 0 )
> +    {
> +        DBGPRINTF("Skipping empty HVM_PARAMS record\n");
> +        return 0;
> +    }
> +
>      for ( i = 0; i < hdr->count; i++, entry++ )

This loop already handles hdr->count == 0.  The additional check is not
required.

> --- a/tools/libxc/xc_sr_restore_x86_pv.c
> +++ b/tools/libxc/xc_sr_restore_x86_pv.c
> @@ -753,15 +753,26 @@ static int handle_x86_pv_vcpu_blob(struct xc_sr_context *ctx,
>      }
>  
>      /* Confirm that there is a complete header. */
> -    if ( rec->length <= sizeof(*vhdr) )
> +    if ( rec->length < sizeof(*vhdr) )
>      {
> -        ERROR("%s record truncated: length %u, min %zu",
> -              rec_name, rec->length, sizeof(*vhdr) + 1);
> +        ERROR("%s record truncated: length %u, header size %zu",
> +              rec_name, rec->length, sizeof(*vhdr));
>          goto out;
>      }
>  
>      blobsz = rec->length - sizeof(*vhdr);
>  
> +    /*
> +     * Tolerate empty records.  Older sending sides used to accidentally
> +     * generate them.
> +     */
> +    if ( blobsz == 0 )
> +    {
> +        DBGPRINTF("Skipping empty %s record for vcpu %u\n",
> +                  rec_type_to_str(rec->type), vhdr->vcpu_id);
> +        goto out;
> +    }

This check for a zero-sized blob should be immediately prior to the

   blob = malloc(blobsz);

So all the other length validation is not skipped.  In particular, some
record types may wish to make zero-length blobs invalid.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  parent reply	other threads:[~2016-07-25 12:21 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-21 17:17 [PATCH RFC 0/4] Fix issues with zero-length records in migration v2 Andrew Cooper
2016-07-21 17:17 ` [PATCH 1/4] docs: Clarify the expected behaviour of zero length records Andrew Cooper
2016-07-25  9:45   ` Wei Liu
2016-07-25 10:21   ` David Vrabel
2016-07-25 10:25     ` Andrew Cooper
2016-07-25 10:35       ` David Vrabel
2016-07-25 10:38         ` Andrew Cooper
2016-07-25 10:44           ` David Vrabel
2016-07-25 10:45             ` Andrew Cooper
2016-07-25 11:18   ` Ian Jackson
2016-07-21 17:17 ` [PATCH 2/4] tools/libxc: Tolerate zero-length records in migration v2 streams Andrew Cooper
2016-07-25  9:46   ` Wei Liu
2016-07-25 12:21   ` David Vrabel [this message]
2016-07-25 12:46     ` Andrew Cooper
2016-07-25 13:00       ` David Vrabel
2016-07-21 17:17 ` [PATCH 3/4] tools/libxc: Avoid generating inappropriate zero-length records Andrew Cooper
2016-07-25  9:45   ` Wei Liu
2016-07-25  9:57     ` Andrew Cooper
2016-07-25 10:14       ` Wei Liu
2016-07-25 10:32   ` David Vrabel
2016-07-25 11:44     ` Ian Jackson
2016-07-25 17:15     ` Ian Jackson
2016-07-26  9:23       ` Wei Liu
2016-07-26 13:37         ` Ian Jackson
2016-07-21 17:17 ` [PATCH 4/4] tools/python: Adjust migration v2 library to warn about " Andrew Cooper
2016-07-25  9:46   ` Wei Liu
2017-03-14 13:20 ` [PATCH RFC 0/4] Fix issues with zero-length records in migration v2 Julien Grall
2017-03-14 13:50   ` Andrew Cooper
2017-03-14 14:21     ` Wei Liu
2017-03-28 18:24       ` Julien Grall

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=57960438.5000208@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).