[Qemu-devel] Possible invalid emulation of rex.W-prefixed far jump

[Qemu-devel] Possible invalid emulation of rex.W-prefixed far jump

[Brad Spengler]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

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.

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.

Thanks for your help, and please keep me on CC for replies

-Brad

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] Possible invalid emulation of rex.W-prefixed far jump

[malc]

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:av1474@comtv.ru