From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NmFzT-00033t-G7 for qemu-devel@nongnu.org; Mon, 01 Mar 2010 19:29:35 -0500 Received: from [199.232.76.173] (port=46603 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NmFzT-00033a-2j for qemu-devel@nongnu.org; Mon, 01 Mar 2010 19:29:35 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NmFzR-0001eD-Qe for qemu-devel@nongnu.org; Mon, 01 Mar 2010 19:29:35 -0500 Received: from grsecurity.net ([209.9.226.146]:55215) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NmFzR-0001e2-K3 for qemu-devel@nongnu.org; Mon, 01 Mar 2010 19:29:33 -0500 Date: Mon, 1 Mar 2010 19:29:20 -0500 Message-ID: <20100302002919.GA29610@grsecurity.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline From: spender@grsecurity.net (Brad Spengler) Subject: [Qemu-devel] Possible invalid emulation of rex.W-prefixed far jump List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I'm writing to report a possible bug in the qemu emulation of=20 rex.W-prefixed far jumps. It affects far jumps of this type with both=20 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=20 to 0xfffc by the & on new_cs from=20 target-i386/op_helper.c:helper_ljmp_protected()) It's suspected that qemu is treating the far address as 16:32 instead of=20 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=20 32bits are 0xffffffff. If qemu is treating the 16:64 layout as 16:32, you can see why new_cs=20 would have the value of 0xffff. The code only fails on qemu -- it works=20 as expected on real systems. I'm not familiar with your code-base so I have no patch for the issue,=20 but I thought I'd fire off a mail as I imagine it's a simple=20 oversight and easy fix for someone familiar with the code. Thanks for your help, and please keep me on CC for replies -Brad --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFLjFvemHm2SUJF1GoRAgmdAJ9dFDKoI2JcPq9lcAO/FFfmfNhedgCeMUic kKCbemhuXKsrKGMI1AhwLlc= =SGGX -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY--