To clarify the current behaviour of kqemu and QEMU with self-writing
code, the following table can be useful:
Supported feature QEMUkqemu
CS.limit no yes
NX bit yes (x86_64 on
I had a similar problem, but only when not using kqemu.
When using a stack overflow exploit, the shellcode provided only
executes when using kqemu. I can attribute this to either the
shellcode being in a different location (maybe someone can clarify
this, is qemu using a different memory layout e
Looks like SELinux to me. Even - you should raise it with whoever
writes your policy.
On Mon, 01 May 2006 23:29:54 +0200
Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> Are you sure that the bug is really in kqemu ? It is possible that
> your guest kernel implements a security system which prevents
You're absolutely right. SELinux was enabled on the host. I disabled it and
now the self modying code runs with kqemu enabled.
So, I guess the current behaviour of qemu (without kqemu) is not really
wanted.
Le Lundi 1 Mai 2006 23:29, Fabrice Bellard a écrit :
> Are you sure that the bug is reall
Are you sure that the bug is really in kqemu ? It is possible that your
guest kernel implements a security system which prevents self modifying
code using segment limits which QEMU does not check (but kqemu checks
them !).
Regards,
Fabrice.
Even Rouault wrote:
Guest OS : Linux 2.6.15-1.2054
Guest OS : Linux 2.6.15-1.2054_FC5 i686 (Fedora Core 5 i386)
Host OS: Linux 2.6.12-10-amd64-k8 #1 x86_64 (Ubuntu 5.10 amd64)
QEMU Version : today CVS compiled with kqemu support
KQEMU : 1.3.0pre6
Binary used : qemu-system-x86-64 (so kqemu user-mode is used)
I'm running the simple C code attached.
