[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [semi-urgent Xen CS question] Re: git commit 9fd67b4ed0714ab718f1f9bd14c344af336a6df7 (x86-64: Give vvars their own page) breaks Xen PV guests (64-bit).


  • To: Andrew Lutomirski <luto@xxxxxxx>
  • From: Keir Fraser <keir.xen@xxxxxxxxx>
  • Date: Tue, 26 Jul 2011 23:20:41 +0100
  • Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
  • Delivery-date: Tue, 26 Jul 2011 15:21:45 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcxL4kDfdZBtWfaEnkuXaRu5ZOUAxA==
  • Thread-topic: [Xen-devel] [semi-urgent Xen CS question] Re: git commit 9fd67b4ed0714ab718f1f9bd14c344af336a6df7 (x86-64: Give vvars their own page) breaks Xen PV guests (64-bit).

On 26/07/2011 22:40, "Andrew Lutomirski" <luto@xxxxxxx> wrote:

> If we go into the iret patch (via auditing, for example), then the
> FIXUP_TOP_OF_STACK macro does movq $__USER_CS,CS+\offset(%rsp), which
> (unless it's buggy) writes __USER_CS into the appropriate spot.
> 
> So I don't see what part of the entry path needs patching.

You'll get Xen's flat CS values loaded if Xen uses SYSRET to return to guest
context. This will happen on return to guest userspace if the guest kernel
calls the iret hypercall specifying the VGCF_in_syscall flag. And that would
typically happen when returning to userspace after a syscall. So I guess the
typical user process will quickly end up using the Xen code selector rather
than Linux's own.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.