From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Vrabel <david.vrabel@citrix.com>
Subject: Re: [RFC PATCH V3 18/22] Implement
	EVTCHNOP_register_extended
Date: Thu, 28 Feb 2013 12:33:49 +0000
Message-ID: <512F4EAD.6000502@citrix.com>
References: <1361975655-22295-1-git-send-email-wei.liu2@citrix.com>
	<1361975655-22295-19-git-send-email-wei.liu2@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1361975655-22295-19-git-send-email-wei.liu2@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Wei Liu <wei.liu2@citrix.com>
Cc: "Keir (Xen.org)" <keir@xen.org>, Ian Campbell <Ian.Campbell@citrix.com>, "jbeulich@suse.com" <jbeulich@suse.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 27/02/13 14:34, Wei Liu wrote:
> Note: this call always fails as it is not yet completed.
> 
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> ---
>  xen/common/event_channel.c |   56 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 56 insertions(+)
> 
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index 26daa7e..bb6e5f9 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1204,6 +1204,34 @@ static long evtchn_register_3level(evtchn_register_3level_t *arg)
>      return rc;
>  }
>  
> +/*
> + * NOTE to extneded event channel users:
> + * extended channels are likely to consume lots large global mapping
> + * area in Xen. For example, 3-level event channel consumes 16 +
> + * nr_vcpus pages global mapping area.
> + */
> +static long evtchn_register_extended(struct evtchn_register_extended *reg)
> +{
> +    struct domain *d = current->domain;
> +    int rc;
> +
> +    spin_lock(&d->event_lock);
> +
> +    switch ( reg->cmd )
> +    {
> +    case EVTCHN_EXTENDED_NONE:
> +    default:
> +        rc = -EINVAL;
> +    case EVTCHN_EXTENDED_L3:
> +        rc = evtchn_register_3level(&reg->u.l3);
> +        break;
> +    }
> +
> +    spin_unlock(&d->event_lock);
> +
> +    return rc;
> +}
> +
>  long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>  {
>      long rc;
> @@ -1312,6 +1340,19 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
>          break;
>      }
>  
> +    case EVTCHNOP_register_extended: {
> +        struct evtchn_register_extended reg;
> +
> +        if ( copy_from_guest(&reg, arg, 1) != 0 )
> +            return -EFAULT;

If the guest's idea of the size of struct evtchn_register_extended is
smaller than Xen's, then Xen may try to copy more data that is actually
available.  This may then return -EFAULT unexpectedly if the guest
allocated the structure at the end of a page and the following page is
not mapped.

David