All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>, Jason Andryuk <jandryuk@gmail.com>,
	Xen-devel <xen-devel@lists.xen.org>,
	Julien Grall <julien.grall@arm.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH v2] xen/vcpu: Rework sanity checks in vcpu_create()
Date: Wed, 12 Sep 2018 09:00:43 -0600	[thread overview]
Message-ID: <5B992A1B02000078001E7E30@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <1536684371-1417-1-git-send-email-andrew.cooper3@citrix.com>

>>> On 11.09.18 at 18:46, <andrew.cooper3@citrix.com> wrote:
> Poisoning idle_vcpu[0] with the sanity debug value isn't actually a clever
> idea, because it passes a NULL pointer check but isn't a usable vcpu.  It is
> also the reason for the (!is_idle_domain(d) || vcpu_id) part of the existing
> sanity BUG_ON().

But you completely discount the intended effect of this poisoning:
During early boot, a NULL deref is liable to not fault, while a deref
of INVALID_VCPU is always going to (on x86 at least).

> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -138,7 +138,21 @@ struct vcpu *vcpu_create(

This patch does not look to be based on current staging.

>  {
>      struct vcpu *v;
>  
> -    BUG_ON((!is_idle_domain(d) || vcpu_id) && d->vcpu[vcpu_id]);
> +    /*
> +     * Sanity check some input expectations:
> +     *  - d->max_vcpus and d->vcpu[] should be set up
> +     *  - vcpu_id should be bounded by d->max_vcpus
> +     *  - Vcpus should be tightly packed and allocated in ascending order
> +     *    (except for the idle domain).
> +     *  - No previous vcpu with this id should be allocated
> +     */
> +    if ( !d->max_vcpus || !d->vcpu || vcpu_id >= d->max_vcpus ||
> +         (!is_idle_domain(d) && vcpu_id && !d->vcpu[vcpu_id - 1]) ||

Note how you still require an is_idle_domain() special case here
anyway.

> +         d->vcpu[vcpu_id] )
> +    {
> +        ASSERT_UNREACHABLE();
> +        return NULL;

I assume you consider it acceptable for release builds to report
back -ENOMEM in the (hopefully indeed impossible) case of
execution going this path?

> @@ -178,16 +192,10 @@ struct vcpu *vcpu_create(
>      if ( arch_vcpu_create(v) != 0 )
>          goto fail_sched;
>  
> +    /* Insert the vcpu into the domain's vcpu list. */
>      d->vcpu[vcpu_id] = v;
> -    if ( vcpu_id != 0 )
> -    {
> -        int prev_id = v->vcpu_id - 1;
> -        while ( (prev_id >= 0) && (d->vcpu[prev_id] == NULL) )
> -            prev_id--;
> -        BUG_ON(prev_id < 0);
> -        v->next_in_list = d->vcpu[prev_id]->next_in_list;
> -        d->vcpu[prev_id]->next_in_list = v;
> -    }
> +    if ( !is_idle_domain(d) && vcpu_id > 0 )
> +        d->vcpu[vcpu_id - 1]->next_in_list = v;

While before this change for_each_vcpu(idle_domain) was
broken only for the (currently impossible on x86 at least) case
of CPU0 not being online (nor parked), afaict it will now be
broken altogether, leading to NULL deref-s when used. Is that
really what you want (if so, the description should say so, and
why that's okay)?

Jan



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

      parent reply	other threads:[~2018-09-12 15:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-06 19:25 [PATCH 0/3] xen: Improvements to the vcpu create/destroy paths Andrew Cooper
2018-09-06 19:25 ` [PATCH 1/3] xen/vcpu: Rename the common interfaces for consistency Andrew Cooper
2018-09-07  9:52   ` Jan Beulich
2018-09-13 10:29   ` Roger Pau Monné
2018-09-17  1:08   ` Julien Grall
2018-09-06 19:25 ` [PATCH 2/3] xen/vcpu: Introduce vcpu_destroy() Andrew Cooper
2018-09-07  9:53   ` Jan Beulich
2018-09-13 10:32   ` Roger Pau Monné
2018-09-06 19:25 ` [PATCH 3/3] xen/vcpu: Rework sanity checks in vcpu_create() Andrew Cooper
2018-09-06 20:07   ` Jason Andryuk
2018-09-06 23:01     ` Andrew Cooper
2018-09-07 10:15   ` Jan Beulich
2018-09-07 19:17     ` Andrew Cooper
2018-09-11 16:46   ` [PATCH v2] " Andrew Cooper
2018-09-12 11:38     ` Jason Andryuk
2018-09-12 15:00     ` Jan Beulich [this message]

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=5B992A1B02000078001E7E30@prv1-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=jandryuk@gmail.com \
    --cc=julien.grall@arm.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --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 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.