All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frediano Ziglio <frediano.ziglio@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>
Cc: <xen-devel@lists.xenproject.org>, <linux-kernel@vger.kernel.org>
Subject: [PATCH] xen: Fix possible user space selector corruption
Date: Thu, 3 Oct 2013 09:24:37 +0100	[thread overview]
Message-ID: <1380788677.30462.1.camel@hamster.uk.xensource.com> (raw)

Due to the way kernel is initialized under Xen is possible that the ring1
selector used by the kernel for the boot cpu end up to be copied to
userspace leading to segmentation fault in the userspace.


Xen code in the kernel initialize no-boot cpus with correct selectors (ds
and es set to __USER_DS) but the boot one keep the ring1 (passed by Xen).
On task context switch (switch_to) we assume that ds, es and cs already
point to __USER_DS and __KERNEL_CSso these selector are not changed.

If processor is an Intel that support sysenter instruction sysenter/sysexit
is used so ds and es are not restored switching back from kernel to
userspace. In the case the selectors point to a ring1 instead of __USER_DS
the userspace code will crash on first memory access attempt (to be
precise Xen on the emulated iret used to do sysexit will detect and set ds
and es to zero which lead to GPF anyway).

Now if an userspace process call kernel using sysenter and get rescheduled
(for me it happen on a specific init calling wait4) could happen that the
ring1 selector is set to ds and es.

This is quite hard to detect cause after a while these selectors are fixed
(__USER_DS seems sticky).

Bisecting the code commit 7076aada1040de4ed79a5977dbabdb5e5ea5e249 appears
to be the first one that have this issue.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
---
 arch/x86/xen/smp.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index d1e4777..2a47241 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -278,6 +278,18 @@ static void __init xen_smp_prepare_boot_cpu(void)
 		   old memory can be recycled */
 		make_lowmem_page_readwrite(xen_initial_gdt);
 
+#ifdef CONFIG_X86_32
+		/*
+		 * Assure we use segments with user level access.
+		 * During switching of task these segments got not reloaded
+		 * so it could happen that userspace tasks get Xen ring1
+		 * selector causing exit with sysenter failures on next
+		 * userspace memory operation.
+		 */
+		loadsegment(ds, __USER_DS);
+		loadsegment(es, __USER_DS);
+#endif
+
 		xen_filter_cpu_maps();
 		xen_setup_vcpu_info_placement();
 	}
-- 
1.7.10.4



             reply	other threads:[~2013-10-03  8:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-03  8:24 Frediano Ziglio [this message]
2013-10-03  9:47 ` [Xen-devel] [PATCH] xen: Fix possible user space selector corruption David Vrabel
2013-10-03  9:47 ` David Vrabel
2013-10-03 10:04 ` Andrew Cooper
2013-10-03 10:04 ` [Xen-devel] " Andrew Cooper
2013-10-03 12:51   ` Frediano Ziglio
2013-10-04 13:20     ` Konrad Rzeszutek Wilk
2013-10-04 13:20     ` [Xen-devel] " Konrad Rzeszutek Wilk
2013-10-04 13:33       ` Andrew Cooper
2013-10-07  9:39         ` David Vrabel
2013-10-07  9:39         ` [Xen-devel] " David Vrabel
2013-10-07  9:48           ` [PATCH v2] " Frediano Ziglio
2013-10-07  9:48           ` Frediano Ziglio
2013-10-07  9:49             ` Andrew Cooper
2013-10-07  9:49             ` Andrew Cooper
2013-10-04 13:33       ` [PATCH] " Andrew Cooper
2013-10-03 12:51   ` Frediano Ziglio
2013-10-03  8:24 Frediano Ziglio

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=1380788677.30462.1.camel@hamster.uk.xensource.com \
    --to=frediano.ziglio@citrix.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xen-devel@lists.xenproject.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.