[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] multi-bytes nop and 64bits

From: M.
Subject: Re: [Qemu-devel] multi-bytes nop and 64bits
Date: Tue, 21 Apr 2009 07:50:49 +0200


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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]