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

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

To: Andrew Lutomirski <luto@xxxxxxx>,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: "j.fitz.inge@xxxxxxxxx" <jeremy@xxxxxxxx>
Date: Tue, 26 Jul 2011 16:37:33 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Tue, 26 Jul 2011 16:39:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CAObL_7Emqw0wg1pkvgYQBF7uPm5xCjFUpWsTso61-WRSoCtFzQ@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> <CAObL_7Emqw0wg1pkvgYQBF7uPm5xCjFUpWsTso61-WRSoCtFzQ@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: K-9 Mail for Android
The correct fix is to just look at the cpl in cs and ignore the rest of the selector.

J
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Andrew Lutomirski <luto@xxxxxxx> wrote:
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
does).

xen_syscall_target does this:

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

/* Normal 64-bit system call target */
ENTRY(xen_syscall_target)
undo_xen_syscall
jmp system_call_after_swapgs
ENDPROC(xen_syscall_target)


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.

--Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>