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

[spender@grsecurity.net (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 --]