[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Possible invalid emulation of rex.W-prefixed far jump
From: |
Brad Spengler |
Subject: |
[Qemu-devel] Possible invalid emulation of rex.W-prefixed far jump |
Date: |
Mon, 1 Mar 2010 19:29:20 -0500 |
User-agent: |
Mutt/1.5.9i |
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
signature.asc
Description: Digital signature
- [Qemu-devel] Possible invalid emulation of rex.W-prefixed far jump,
Brad Spengler <=