[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Possible invalid emulation of rex.W-prefixed far jump
From: |
malc |
Subject: |
Re: [Qemu-devel] Possible invalid emulation of rex.W-prefixed far jump |
Date: |
Wed, 3 Mar 2010 20:34:09 +0300 (MSK) |
User-agent: |
Alpine 2.00 (LNX 1167 2008-08-23) |
3On Mon, 1 Mar 2010, Brad Spengler wrote:
> Hi all,
>
> I'm writing to report a possible bug in the qemu emulation of
> rex.W-prefixed far jumps. It affects far jumps of this type with both
> rip-relative and absolute addresses.
Looks like it's a bug indeed, here's a test case:
.data
#define REX
#ifdef REX
jmp_off: .quad longproc
#else
jmp_off: .long longproc
#endif
jmp_seg: .long 0
msg0: .ascii "Hello\n"
msg1: .ascii "Jump target reached\n"
msg2: .ascii "Bye\n"
msg3:
.text
.globl _start
show:
xor %rax,%rax
inc %rax
mov %rax,%rdi
syscall
retq
_start:
lea msg0, %rsi
mov $(msg1-msg0), %rdx
call show
mov %cs, jmp_seg
#ifdef REX
.byte 0x48
#endif
ljmp *jmp_off
back:
lea msg2, %rsi
mov $(msg3-msg2), %rdx
call show
mov $60, %rax
syscall
longproc:
lea msg1, %rsi
mov $(msg2-msg1), %rdx
call show
jmp back
To build:
gcc -m64 -o test -nostartfiles test.S [-DREX]
>
> The yasm syntax for these instructions:
> jmp far qword [addr]
> jmp far qword [addr wrt rip]
>
> and the resulting disassembly:
> 8: 48 ff 2c 25 00 00 00 00 rex.W ljmpq *0x0 c: R_X86_64_32 .text+0x17
> 10: 48 ff 2d 00 00 00 00 rex.W ljmpq *0x0(%rip) # 0x17
>
> qemu triggers a gpf with error 0xfffc (presumably this is 0xffff masked
> to 0xfffc by the & on new_cs from
> target-i386/op_helper.c:helper_ljmp_protected())
>
> It's suspected that qemu is treating the far address as 16:32 instead of
> 16:64 as it should, since the far address as laid out in memory is:
> 12 34 56 78 ff ff ff ff 10 00
>
> The far address is intended to be a Linux kernel address, so the upper
> 32bits are 0xffffffff.
>
> If qemu is treating the 16:64 layout as 16:32, you can see why new_cs
> would have the value of 0xffff. The code only fails on qemu -- it works
> as expected on real systems.
>
> I'm not familiar with your code-base so I have no patch for the issue,
> but I thought I'd fire off a mail as I imagine it's a simple
> oversight and easy fix for someone familiar with the code.
>
The code in translate.c (line 4573 and bellow) doesn't even look at REXW.
> Thanks for your help, and please keep me on CC for replies
Thanks for the bug report.
--
mailto:address@hidden