WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [RFC, PATCH 7/24] i386 Vmi memory hole

To: Chris Wright <chrisw@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC, PATCH 7/24] i386 Vmi memory hole
From: Zachary Amsden <zach@xxxxxxxxxx>
Date: Wed, 15 Mar 2006 01:18:32 -0800
Cc: Andrew Morton <akpm@xxxxxxxx>, Joshua LeVasseur <jtl@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Pratap Subrahmanyam <pratap@xxxxxxxxxx>, Wim Coekaerts <wim.coekaerts@xxxxxxxxxx>, Jack Lo <jlo@xxxxxxxxxx>, Dan Hecht <dhecht@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Christopher Li <chrisl@xxxxxxxxxx>, Virtualization Mailing List <virtualization@xxxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxx>, Anne Holler <anne@xxxxxxxxxx>, Jyothy Reddy <jreddy@xxxxxxxxxx>, Kip Macy <kmacy@xxxxxxxxxxx>, Gerd Hoffmann <kraxel@xxxxxxx>, Leendert van Doorn <leendert@xxxxxxxxxxxxxx>, Ky Srinivasan <ksrinivasan@xxxxxxxxxx>, Dan Arai <arai@xxxxxxxxxx>
Delivery-date: Wed, 15 Mar 2006 10:25:35 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20060315090935.GS12807@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <200603131804.k2DI4N6s005678@xxxxxxxxxxxxxxxxxxx> <20060314064107.GK12807@xxxxxxxxxxxxxxxxxx> <44166D6B.4090701@xxxxxxxxxx> <20060314215616.GM12807@xxxxxxxxxxxxxxxxxx> <4417454F.2080908@xxxxxxxxxx> <20060315043108.GP12807@xxxxxxxxxxxxxxxxxx> <4417CFDA.1060806@xxxxxxx> <4417D212.20401@xxxxxxxxxx> <20060315090935.GS12807@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5 (X11/20051201)
Chris Wright wrote:
* Zachary Amsden (zach@xxxxxxxxxx) wrote:
ENTRY(sysenter_entry)
       movl TSS_sysenter_esp0(%esp),%esp
sysenter_past_esp:
       STI
       pushl $(__USER_DS)
       pushl %ebp
       pushfl
       pushl $(__USER_CS)
       pushl $SYSENTER_RETURN

SYSENTER_RETURN is a link time constant that is defined based on the location of the vsyscall page. If the vsyscall page can move, this can not be a constant. The reason is, this "fake" exception frame is used to return back to the EIP of the call site, and sysenter does not record the EIP of the call site.

It's only real issue for something like execshield.  For this it's easy
to do the fixed math since it's still at fixed address.

+       DEFINE(VSYSCALL_BASE, (PAGE_OFFSET - 2*PAGE_SIZE));

Ok, I'm confused. What fixed math? The return EIP that is pushed here is used when sysenter is active and you have to IRET back to userspace. If that EIP is dynamically relocatable, you can't do fixed math unless you patch the pushl site dynamically. Notable reasons for returning via IRET on this fake exception frame were (until my recent submission) IOPL changes, but I believe there were more. I will have to inspect the source to determine if that is still the case.

Zach

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