From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lw8sj-000715-EO for qemu-devel@nongnu.org; Tue, 21 Apr 2009 01:50:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lw8si-00070n-2N for qemu-devel@nongnu.org; Tue, 21 Apr 2009 01:50:56 -0400 Received: from [199.232.76.173] (port=57755 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lw8sh-00070k-OU for qemu-devel@nongnu.org; Tue, 21 Apr 2009 01:50:55 -0400 Received: from lamune.ookoo.org ([88.191.88.38]:44811) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lw8sh-0000eT-7Z for qemu-devel@nongnu.org; Tue, 21 Apr 2009 01:50:55 -0400 Received: (PMaild 67630 invoked for remote email qemu-devel@nongnu.org); Tue, 21 Apr 2009 07:50:50 +0200 Subject: Re: [Qemu-devel] multi-bytes nop and 64bits From: "M." =?ISO-8859-1?Q?Karpel=E8s?= In-Reply-To: References: <1240249899.9112.2867.camel@localhost> Content-Type: text/plain; charset="UTF-8" Date: Tue, 21 Apr 2009 07:50:49 +0200 Message-Id: <1240293049.9112.3527.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi, Le mardi 21 avril 2009 à 02:10 +0400, malc a écrit : > On Mon, 20 Apr 2009, Mark Karpeles wrote: > > As seen by qemu (QEMU PC emulator version 0.10.1): > > > > 0x0000000000201000: (bad) > > 0x0000000000201002: add %bpl,%cl > > 0x0000000000201005: sub %edx,0x0(%rcx) > > 0x0000000000201008: add %al,(%rax) > > 0x000000000020100a: add %al,(%rax) > > (The code after this line is not meant to be executed, it's read-only > > data, and so the system will crash) > The disassembler is disconnected from the main translation engine, so > what you see (produced by the older version of i386 disassmbler from > GNU binutils) might not be what QEMU actually translates/executes. To > be sure use gdbstub and recent GDB to see, hopefully, more coherent view. Oh my... I checked more and tried running this without the qemu debug mode "in_asm", and it's working indeed. So, in_asm will decompile memory until it reaches a "stop" operation (ret, %cr3 changed, etc), however if it doesn't reach such an operation it will continue reading memory. I wasn't expecting this bug because the fact it was continuing to read memory caused a page-fault which was catched by the kernel I'm writing. I never though the debugger could trigger stuff like OS pagefaults (and of course it was happening with %rip exactly pointing to a long nop, that's why I wasn't understanding the origin of the page fault). Maybe this could be added to some documentation: "If guest OS crashes because of a page fault on a long nop operation, try disabling in_asm debugging mode". Or maybe this debugging mode could be fixed to handle long nops? This debugging mode is really helpful to understand what happened during a crash, and for people writing their own kernel (like me) it's a life savior. I'm not sure how the decompiler works in qemu, but I'll have a look and see if anything can be done to at least prevent it throwing pagefaults on bogus addresses when a long nop happens. Anyway thanks for the tip, you just saved me more days of head scratching. Mark