xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Tim Deegan <tim@xen.org>, Keir Fraser <keir@xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 2/3] x86/percpu: Force INVALID_PERCPU_AREA into the non-canonical address region
Date: Thu, 26 Sep 2013 11:04:43 +0100	[thread overview]
Message-ID: <524406BB.8020208@citrix.com> (raw)
In-Reply-To: <1380188966-26665-3-git-send-email-andrew.cooper3@citrix.com>

On 26/09/13 10:49, Andrew Cooper wrote:
> This causes accidental uses of per_cpu() on a pcpu with an INVALID_PERCPU_AREA
> to result in a #GF for attempting to access the middle of the non-canonical
> virtual address region.
>
> This is preferable to the current behaviour, where incorrect use of per_cpu()
> will result in an effective NULL structure dereference which has security
> implication in the context of PV guests.

This could do with clarifying somewhat.

The security concern is simply dereferencing a NULL pointer in the
context of a PV guest, not from any specific use of this code.

This patch simply prevents Xen from accidentally dereferencing a NULL
pointer in the case of an offline pcpu.  As there are no guest
hypercalls which should be able to cause this, there is no specific
security issue here.  The previous patch fixes the case where toolstack
hypercalls could cause this behaviour.

~Andrew

>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Tim Deegan <tim@xen.org>
> ---
>  xen/arch/x86/percpu.c |    9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/percpu.c b/xen/arch/x86/percpu.c
> index e545024..1c1dad9 100644
> --- a/xen/arch/x86/percpu.c
> +++ b/xen/arch/x86/percpu.c
> @@ -6,7 +6,14 @@
>  #include <xen/rcupdate.h>
>  
>  unsigned long __per_cpu_offset[NR_CPUS];
> -#define INVALID_PERCPU_AREA (-(long)__per_cpu_start)
> +
> +/*
> + * Force uses of per_cpu() with an invalid area to attempt to access the
> + * middle of the non-canonical address space resulting in a #GP, rather than a
> + * possible #PF at (NULL + a little) which has security implications in the
> + * context of PV guests.
> + */
> +#define INVALID_PERCPU_AREA (0x8000000000000000L - (long)__per_cpu_start)
>  #define PERCPU_ORDER (get_order_from_bytes(__per_cpu_data_end-__per_cpu_start))
>  
>  void __init percpu_init_areas(void)

  reply	other threads:[~2013-09-26 10:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-26  9:49 [PATCH 0/3] per_cpu() fixes Andrew Cooper
2013-09-26  9:49 ` [PATCH 1/3] x86/idle: Fix get_cpu_idle_time()'s interaction with offline pcpus Andrew Cooper
2013-09-26  9:49 ` [PATCH 2/3] x86/percpu: Force INVALID_PERCPU_AREA into the non-canonical address region Andrew Cooper
2013-09-26 10:04   ` Andrew Cooper [this message]
2013-09-26  9:49 ` [PATCH 3/3] DO NOT APPLY - debugging code for gpf when accessing invalid per_cpu() data Andrew Cooper
2013-10-03 17:55 ` [PATCH 0/3] per_cpu() fixes Andrew Cooper
2013-10-03 19:52   ` Keir Fraser

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=524406BB.8020208@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --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).