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/
Home Products Support Community News


Re: [Xen-devel] [semi-urgent Xen CS question] Re: git commit 9fd67b4ed07

To: Keir Fraser <keir.xen@xxxxxxxxx>
Subject: 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).
From: Andrew Lutomirski <luto@xxxxxxx>
Date: Tue, 26 Jul 2011 17:40:48 -0400
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Tue, 26 Jul 2011 14:42:29 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=3oMPezGhrFrk1bvw9xqZtGP2rrGMjf9gpJYwlIp4sEw=; b=V53VFK4C46eXBQ2bjP0Y+J7usw8DZrUBgrVAiExCq43gksi38KTDRLKiaRocRWju0L OiCxu+g2CAUAJpI/+NEqtjez0ySLn85KbKHlRgyBKq9r2zNd3UlZxecp0c2rz8xJfUU4 IDlc2oF+gE1+x1WRG+i1Z1R9+b+xCR2h0HHNA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CAObL_7G31QbwkRdmzf8ABFTmsKbmca=KPkQNM2J_jgT6VG6JqQ@xxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <CAObL_7HYJLN3Eq2Q4ESuU4=4230Xs37C6Jqn1OYApr2LXTvo3Q@xxxxxxxxxxxxxx> <CA54E6A4.1E91B%keir.xen@xxxxxxxxx> <CAObL_7G31QbwkRdmzf8ABFTmsKbmca=KPkQNM2J_jgT6VG6JqQ@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, Jul 26, 2011 at 5:10 PM, Andrew Lutomirski <luto@xxxxxxx> wrote:
> On Tue, Jul 26, 2011 at 4:48 PM, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
>> On 26/07/2011 20:08, "Andrew Lutomirski" <luto@xxxxxxx> wrote:
>>> On Tue, Jul 26, 2011 at 11:32 AM, Konrad Rzeszutek Wilk
>>> <konrad.wilk@xxxxxxxxxx> wrote:
>>>> On Mon, Jul 25, 2011 at 09:50:30PM -0400, Andrew Lutomirski wrote:
>>>>> After staring at the Xen assembly code with vague comprehension, I
>>>>> think I can sort of understand what's going on.
>>>> Ok.
>>>>> Can you run this little program on a working kernel and tell me what
>>>>> it says (built as 64-bit and as 32-bit (with -m32)):
>>>> 32-bit:
>>>> [konrad@f13-x86-build ~]$ ./check
>>>> cs = 73
>>>> [konrad@f13-x86-build ~]$ uname -a
>>>> Linux f13-x86-build.dumpdata.com 3.0.0 #1 SMP PREEMPT Tue Jul 26 09:56:38 
>>>> EDT
>>>> 2011 i686 i686 i386 GNU/Linux
>>>> 64-bit:
>>>> [konrad@f13-amd64-build ~]$ ./check
>>>> cs = e033
>>> My best guess is that each task starts out with standard __USER_CS,
>>> but the code in write_stack_trampoline (in the hypervisor) tells the
>>> kernel that CS is 0xe033 and then the next return to userspace makes
>>> it true.
>> Yes, that's right.
> But it's still weird, because AFAICT xen_sysret64 already does the
> right thing.  So presumably the failure case only happens when
> something prevents sysret from working, like CONFIG_AUDITSYSCALL.

I lied.  I still don't see what's going on.

Xen, in enlighten.c, registers xen_syscall_target as the 64-bit
syscall target (or at least I assume that's what CALLBACKTYPE_syscall

xen_syscall_target does this:

.macro undo_xen_syscall
        mov 0*8(%rsp), %rcx
        mov 1*8(%rsp), %r11
        mov 5*8(%rsp), %rsp

/* Normal 64-bit system call target */
        jmp system_call_after_swapgs

So the 0xe033 that Xen writes is popped back off the kernel stack and ignored.

xen_sysret64 explicitly pushes __USER_CS as its CS value, so that path looks OK.

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.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>